Under what circumstances is it necessary, if ever, to save a change to a stand-alone database? Some older posts suggested that changes that had been made programmatically were not automatically saved. But I need to be confident that changes are saved, regardless of how those changes were made.
Why not just SAVE at the end of your session?
If you use startdatabasechange, so that changes can be undone, then changes will be saved.
I think that the Save statement only saves the active database, and there about 15 DBs open in the application I am working on. And that would depend on a user doing something, which I would like to avoid. I could go back and add startdatabasechange statements, and I have used it in several places, but that would be a big chore.
I also confirmed that under some circumstances that changes made by a procedure will not be saved automatically.
I have set up a Home form and disabled the red button, so it will remain open until PanX is quit. Since posting my question, I wrote a procedure to loop through the open databases and save then close each one and put a button to run it on the Home form.
Each of the databases is set to “Always keep open…” so if the user closes the last window, the database will still be open.
The only remaining question, is there a way to intercept command-Q or shift-command-W? I have not looked into whether custom menus could do this.
In a stand-alone, I always put a save at the end of a procedure and anywhere during the process where I need it as well. For example, making a second stand-alone active, making a change, save, then going back to the original or another database.
I just ran a procedure creating a new hotkey with Command-W…
definehotkeys "global","command-w",{nop}
This seems to take precedence over the same menu shortcut and does nothing when pressed. I haven’t tried Comman-Q but would guess it would act the same way. Instead of a nop you could have it popup a warning or a message with further instructions.
If your code makes changes that you want saved, you should include save statements at that point. This is no different than earlier versions of Panorama.
If you are making modifications to multiple databases, you’ll need a save statement for each. But that should be easy since in order to modify a database, that database must be active. So the fact that the save statement saves the current database is exactly what you want. For example, you could do this:
Field=value
save
setactivedatabase "some other db"
OtherField=othervalue
save
Whenever you modify a database, then you immediately save it.
It’s hard for me to imagine an application where this could be needed, but you could build a system with timers so that if you modified a database multiple times in a procedure it would only be actually saved once at the end. This would be good for performance if your databases are large. I’m not going to go into detail about how this would be done but this is exactly how Panorama Server works. You can look at the source code for the WEBSAVEZERO and BACKGROUNDWEBSAVE procedures to see how this was done (I’m pretty sure that the source code for these procedures is available to you). But I suspect this would be massive overkill for your application.
There is no way to trap close and quit. Trapping the command keys is insufficient, these operations can also triggered from the menus, and from the dock. macOS is not architected in such a way that it is possible to run arbitrary Panorama code when these operations are triggered.
You could easily make a procedure that saves multiple databases.
dblist = parameter(1)
looparray dblist,cr(),db
setactivedatabase db
save
endloop
setactivedatabase ""
Then you could do something like this:
call "SaveMultiple","Accounts"+cr()+"Contacts"+cr()+"Invoices"
or even
call "SaveMultiple",info("files")
Even better, you could make this a custom statement.
Note - if you do this with info(“files”) to save all databases, it might be kind of slow. Also you might save databases you don’t actually want to save. I don’t really recommend this idea, but people often seem to like ideas I don’t recommend. 