In Pan6, if I enter a new record and then do Command-Up (staying selected in the first field) the db is sorted and I can see the new record in position, together with its neighbors.
Then I can do Command-All to move to the first record, if needed.
In PanX, if I enter a new record and do Command-Up (staying selected in the first field) the db is sorted and I jump directly to the first record. I have lost the possibility of seeing the new record in real position.
The behavior of Pan6 looks preferable to me, especially now that No Duplicates is not implemented.
As was said by RAmeeti several times, and I certainly agree, unless it is imposed by Apple, or there is a mistake, or it is a clear improvement, it would be better if the general behavior of PanX was following the behavior of Pan6.
Regardless of how Panorama 6 may have behaved, I for one would really like it if, after sorting, the currently selected record were still selected (and visible). The purpose of sorting is sometimes to move the just-edited record into place, and it would be a very nice touch if we could see that that has indeed happened.
As far as I know this Pan 6 feature has not been implemented in Panorama X.
But you can let Panorama X do almost everything you imagine. I just tested the following approach where I copy the content of the entire record, sort the database and find my copied record again. This should work for all databases (i.e. without unique ID fields).
local SearchString
SearchString = exportlinenotabs()
field «YourSortField»
sortup
find exportlinenotabs() = SearchString
You could also use the info(“serverrecordid”) to quickly navigate to the previous selection:
let theRecord=info("serverrecordid")
field «YourSortField»
Sortup
find info("serverrecordid")=theRecord
Since this use of the info(“serverrecordid”) function is just temporary there is no chance of it changing while the procedure runs. And, yes, as I learned myself in the past, this works in all standalone databases and is not limited to the Panorama X Server.
Another similar approach is to use the serverrecordid. PanX assigns a unique id to each record which you can show with info(“serverrecordid”).
let lvrecid=info("serverrecordid")
[sort statements]
find info("serverrecordid")=lvrecid
One should remember that the serverrecordid is not a permanent assignment and can (or will) change under certain conditions (if I recall correctly, when a new server generation is created).
Thanks, KJM! I had been fiddling with the pleaseselectall statement, but wasn’t making any progress. The notabs thing is interesting.
Actually what this one case is derives from a nifty kludge (which I mean in the most flattering terms) I got on an earlier Panorama forum some years or even decade+ ago. What I needed in a checking account DB with over 1000 records in it is to go to whatever record’s date is closest to today, but to continue to show all records. Pan6 using theold trick would make that record active and then just do a record# sort, keeping the active record active now in its proper place. So I combined your code with the old “delta” routine and is works.
Yes, all the record id numbers can (and usually do) change when a new server generation that changes the field structure is uploaded. Not when only forms, procedures or field options are changed.
In this application, though, the ID number will not change, so the solution proposed by Gary and Tom is fine (and will work in single user databases also).
All of these recent posts involve running a procedure. What most of us want is for the selected record to stay selected after a simple CMD-U keystroke.
ABSOLUTELY! ALong with sort down, etc. Will the Pan 6 behavior be implemented that keeps the selected record displayed. I’m having to write procedures in numerous databases to take into consideration UP, DOWN, all just more work. I hope this is in the next release so I can at least not have to do all this.
I think I addressed this in another thread on this forum some time ago, but let me repeat it here. This change was intentional. In the past we received many tech support inquiries from customers that were confused by the way that sorting worked. When they sorted alphabetically, they expected to see entries starting with A, B, C, etc. When they didn’t, they thought that sorting was not working and would contact us. I’m sure that some did not contact us, and just decided that the program didn’t work and abandoned it. This happened quite a lot, so the decision was made to change it to work the way most new users expected it to. I’m sorry that this has negatively affected some users, sometimes it’s not possible to make everyone happy.
Leo, if writing the two extra lines of code when you sort is more than you care to do, you could use a custom statement that would perform the sort and then return to the previously selected record. I have statements called mysortup and mysortdown, so I can use these statements in lieu of sortup and sortdown. If you don’t know how to create a custom statement, it’s not difficult and Michael Kellock has prepared a sheet with instructions that I am sure he would share.
