Panorama has a lot of trouble with stray clicks that can cause confusion as to which file it’s dealing with. It doesn’t seem limited to shared files.
With Panorama running in the background, and a procedure opens another file. If the file being opened has a window sizing in its initialize procedure, the already open window gets resized instead. If Panorama is active, it doesn’t happen.
Below is a simple example that easily demonstrates it with two barebones files: FileA and FileB.
FileA has one procedure:
Wait 5
OpenFile "FileB"
In this example, the wait is to give me time to click on the desktop, another window, or activate another app.
FileB has only an .Initialize procedure: Zoomwindow 50,50,500,500,"NoToolBar NoScroll"
Save FileB at some other dimensions and close it. Run the open file procedure in FileA, and if Panorama is active, FileB gets resized. If Panorama is not active, FileA gets resized.
Manually change their dimensions, save and try again. It’s 100% repeatable.
Or, during that wait, click to a window in another Panorama file. The .Initialize of FileB doesn’t run until you click to make FileA active again.
If multiple files are being opened as a set, any of the above scenarios disrupts the process. In some cases menus or forms get loaded to the wrong database. Fortunately, closing and re-opening corrects it.
Exactly as documented. Please see the discussion of scope in the documentation for the wait statement.
Wait (and timers, which wait is based on) give you the ability to run asynchronous code. If you want to write asynchronous code, you have to be super careful about what state you are in when the code starts running in.
You got me on a technicallity then in trying to recreate it.
I experience the exact issues described without using wait. For instance, a stray click while a file set is opening and initializing runs it off the rails as described.
A file that is opened by a procedure resizes a form in the calling database if Panorama is not active. No wait involved. It happens routinely.
It’s not clear whether or not my error in trying to provide an example has caused this to be dismissed, but the issue of stray clicks is real.
When initializing a file set of shared files, if a user clicks on on of the first files to open, graphic elements of another file that is initializing will appear in the activated file - the one the user has just clicked on.
With a procedure running a loop to generate PDFs, I inadvertently clicked on the Desktop and caused a variable error message to pop up up in Panorama. When I clicked OK the procedure stopped as would be expected.
(This post had additional info about problems with corrupted PDFs generated in a looping production. That appears to be a separate issue and has been reposted as such)
JimC - as an aside, I’m guessing you had an M2 before the M4. When you switched up to the M4, was the performance improvement “Wow!” or “Meh”?
As an aside, aside: I wish they could take some of this AI pixie dust and, behind the scenes, engage more “multi-core” action in standard apps. That is, not require a whole app re-write using arcane techniques.
I understand that if the coded algorithm is step-by-step, re-wrangling it to use multi-core would be a … challenge. Not all actions would lend themselves to improvement, but I’m guessing a new Sort algorithm would be a candidate. A girl can dream.