Hello Everyone!
Is there a blockmouse function? In other words, is there an equivalent to blockkeyboard, but for the mouse?
Thanks!
No, there isn’t, and I don’t believe such a feature is possible for macOS.
One thing you could do is open a modal dialog. That would block any mouse input to other Panorama windows. It won’t prevent other applications from receiving mouse input, however.
In general, however, blocking user input events is not a very Mac thing to do. Panorama itself uses blockkeyboard for very short time periods, for example when opening a dialog. This is simply to allow typeahead into a dialog – the key events are saved until the dialog is read for them. But there is no such thing as “mouseahead”, you would never want to queue up mouse events for later.
Thank you Jim.
My goal is to minimize the number of stray clicks while my databases run there .Initialize procedures. Unusual things seem to happen, when I open a database, and click onto another window while that database is initializing. For example, the long sequences of numbers being randomly copied into field (mentioned on a previously post), seems to only happen when I click on a window during an .Initialize procedure, or attempt to preform some other action, such as a search.
The modal dialog stops the .Initialize procedure, so it seems likely to not be of help here.
My other thought is to have a form pop up with a progress indicator, notifying the user to chill. But, I was hoping for something more ironclad, so to speak.
I have for a long time used modal windows to prevent stray clicks from mucking up a procedure that takes a long time to run (seconds, that is, where a user might click something). The modal window does not prevent a procedure from running. But it will stop a window from opening, if that happens to be part of your .Initialize procedure. Of course, that is on Jim’s no-no list for the .Initialize procedure.
In my case I have a form named “PleaseWait”; it is opened with opendialog. The message is set in a fileglobal variable before it is opened. And you need to be sure that the procedure will not end, with an error for example, before reaching a closedialog statement. Or you can put a close box on the form with a closedialog statement.
Starting a couple of years ago, Panorama now ignores all clicks and keys while a procedure is running. For example, try a procedure like this:
loop
nop
until 2000000
message "done"
While this procedure is running, all clicks on items within Panorama windows will be ignored. You can click on a different Panorama window, but it won’t become active (i.e. the procedure will still think it is running in the old window) and you won’t be able to click on any items in window. You also can’t choose any menu items.
SInce clicks and keys are ignored already, you may wonder why there is a blockkeyboard function at all. This was created specifically for complicated dialogs like Find/Select. When the Find/Select dialog runs, there are multiple procedures that run, with a short gap in between. Without the blockkeyboard function, typeahead would not work in these complicated dialogs.
The bottom line is that Panorama is already blocking stray clicks while procedures are running (it didn’t always do that, but it does now). Whatever problem you are seeing lies elsewhere.
OK, that is good news.
Is it possible for stray clicks to occur when the database opens auxiliary databases?
Clicks are blocked whenever procedure code is running. Auxiliary databases are opened via a procedure, so no, there should be no stray clicks.
So I guess my PleaseWait procedure is not needed to avoid stray clicks, but it does alert a user that something is happening.
If I am correct, when mouse clicks and key strokes are disabled, many menu items are grayed out, easily seen under the File menu. I have occasionally had PanX get stuck in that condition, ignoring clicks and keys, except it will show the File menu items in response to the mouse, until Panx is quit (or maybe Force-Quit; I don’t remember which one).
Has anyone else experienced this?
Yes.
I’ve also had to get clients on a couple of projects to learn to keep their hands off the mouse and keyboard while a file set is initializing. That includes switching to another app. Otherwise we have errors 100% of the time.
In both cases there are a number of related files loading and sharing data, along with forms displaying tables and tab panels.
Yep. By the way, it was suggestions from you that motivated me to add blocking of key/mouse events while procedures were running.
Yes. The goal was for all menu items to be grayed out, but a few are under Apple’s control and couldn’t be. But even those don’t do anything when you select them (other than items in the Apple menu).
Sure, absolutely. That’s what happens if a procedure runs forever in an infinite loop. Fortunately Panorama now has facilities to mostly prevent this.
http://www.provue.com/panoramax/help/preventing_endless_loops.html
It is, however, still possible (though difficult) to cause an infinite loop, and in some cases as explained on the page above, you might even want to do that intentionally. If Panorama does get into an infinite loop, you have to Force Quit.
It used to be that you could actually use Panorama while an endless loop was running - click on things, use menus, launch other procedures, etc. So in these situations, you might not even realize that a loop was running, other than possibly Panorama would run slowly or behave weirdly.
However, unless you’ve disabled it, you should usually be able to use SHIFT-COMMAND-ESCAPE to abort an infinite loop.