I have a procedure that makes a selection, then calculates some variable values, then makes a new selection, does some more variable calculations. I then want to go back to the first selection. So I inserted a startdatabasechange “allrecords”,“Select new records” statement, and later inserted a revert statement.
I thought this would take me back to the earlier selection. There are no saves in between, and no changes to the data.
But the procedure is stopping when it encounters the revert statement. I can then go to the Edit menu and undo the changes, but I had hoped to do that programatically.
Am I misunderstanding what is supposed to happen? Or are things not working as intended, i.e. a bug?
You are correct - I jumped the gun without looking that up in the Help file. You might have to use an applescript to execute a command-Z keystroke to accomplish that.
The startdatabasechange statement makes procedures / procedure steps undoable. That implies the use of the menu item Edit > Undo (or cmd-Z).
The revert statement restores the database in its last saved status. It has nothing to do with startdatabasechange and Undo. You could save your database after the first selection, but you would lose the results of your calculations (except you saved them elsewhere).
It might be easier to reuse your earlier procedure code to redo your first selection.
Here is an example I just tried which seems to make a change and then undo it using an applescript to trigger the command-Z key and return from whence we came.
startdatabasechange "AllRecords","Test Action"
sortup
applescript {tell application "System Events"
delay 0.5
key code 6 using command down
end tell}
No, I don’t think so. But there is an unsupported method that I think will do what you are asking.
The action would be undo:, so the code would be:
sendaction "undo:"
I’m not really fond of what you are proposing as a coding technique.
What does this mean? I wonder if you could simply use the aggregate( function, and not do any selections at all (thus not need to undo the selections).
Now my feelings are hurt. Of course, I would use aggregate when possible rather than making a selection. I have long thought this was one of the best additions to PanX since I learned of it in the first course you gave. But in my case, I am creating arrays using arrayselectedbuild, so aggregate is not going to the job.
No reason you would have. The undo: action is not mentioned in the documentation – you would have to be familiar with the Objective-C runtime to know this was available. (Even access to the Panorama source code wouldn’t help you on this – the undo: action is part of Apple’s code, not Panorama’s. I didn’t put a complete list of available actions in the documentation because I don’t have access to a complete list myself.)
Sorry, I didn’t mean to do that!
Me too! But I don’t think very many people use it.
Uh-oh, I might hurt your feelings again, if so apologies in advance. In Panorama X the arraybuild( function has an optional query parameter, that allows you to build an array based on a subset of the database, without having to first select the subset. So instead of a two step select followed by arrayselectedbuild, you can just use arraybuild( with a query formula. I actually use this even more than the aggregate( function.
Note that the arrayselectedbuild( function can also include a query formula, but it will only apply the query to selected records. You could also do this with the arraybuild( function by using info(“visible”) in the query formula. But I think in your case (and most cases) I wouldn’t mess with selection at all, just build the array based on the query formula. Then you won’t need to worry about undoing the selection, or even about what the current selection state of the database is.