While working on a procedure, I inserted a wait in order to observe what record was being selected as it worked through a LoopArray.
I kept getting errors that seemed to be all over the place with every run of the procedure getting a different error. Many were that a field didn’t exist when it clearly did. Without changing a thing the next run would complain that a different field didn’t exist. Some of those errors named it as non-existent in _PanoramaLib.
Hmmm.
I removed the wait and the procedure ran completely with no further issues.
This would possibly explain a lot of the issues I dealt with over a period of months, with many posts here. Is wait opening _PanoramaLib or giving it the opportunity to activate via a background timer?
I think you can see that wait 30 is a lot easier to write. However, like any timer, you have to be mindful that something could have changed during the delay.
It sounds like the delay statement is really what you wanted to use here. That delays but does not allow the computer to do anything else during the delay. (Delay just loops with a nop until the specified time has passed.)
I’ve set up a timer as the last block of code in .Initialize to run after .Initialize finishes to call several procedures which as I understand it should not be called directly from .Initialize. These prepare the computer for the day’s work in our factories without relying on users to initiate the process.
The timer runs for between 5 and about 30 seconds, depending on how many emails have to be imported into Panorama. Any mouse or keyboard activity during this period can interfere with and even halt the procedures before they complete. My solution is to set an initial window covering the entire screen (with the message “Do not use mouse or keyboard”) which is closed in the final line of the timer, revealing the form windows with the latest data set up for the day’s work.
The large window works quite well, but I wondered if there is a better, foolproof way of preventing user interference.
Your understanding is outdated. What you are doing used to be necessary, but it isn’t any more - because .Initialize is actually already called as timer code. I believe this started in one of the 10.2 beta releases, but I don’t remember exactly which one.
On the other hand, instantiating a timer from a timer is fine - so what you are doing won’t cause a problem. It’s just an extra unnecessary step.
This is also outdated. Recent versions of Panorama lock out all mouse and keyboard input until the procedure is finished. This is for any procedure - whether it is a regular procedure or run as a timer. (However, there is no way to prevent the user from switching to another application, but your procedure should continue to run.)
That’s really good to know, thank you. I have removed the timer code and make the procedure calls directly from .Initialize, and it is working perfectly.
I was aware of this recent lockout feature, but I seem to have found a use which defeats it. These procedures use AppleScript code to import text from Mail emails into Panorama, opening and closing Mail windows while the Panorama procedure is running. A user occasionally inadvertently stops the process before completion by clicking on the screen and I guess this halts Mail and/or AppleScript which stops the PX procedure.
So I’d still like to find a foolproof method of preventing mouse and keyboard use while these procedures are running.
Sorry, there’s nothing Panorama can do about clicks on other applications.
Actually, my statement that Panorama “locks out all mouse and keyboard input” is not technically accurate. Apple doesn’t provide any way to do that. When you click on a window, that’s handled by Apple’s code, not Panorama’s (even if it is a Panorama window). The solution was to configure the window to ignore the click. However, Panorama can’t configure windows that don’t belong to it.
