I have a database where invoices and payments are recorded. In order to test the internal consistency of the data, I wrote a procedure that will go through each payment in a given month and run five different tests for consistency. This can take several minutes, and while that is happening, nothing happens on the screen.
If a user clicks on a window of another database while the procedure is running, the procedure immediately fails because the active database has changed. So I have big warning on the screen not to do that. But I would like to prevent this type of failure regardless of any stray clicks.
My question is: can I disable any user input in PanX while the procedure is running, so it would not recognize any mouse clicks or key strokes?
My first thought: I would try to avoid such time-taking procedures. In most cases formulafill statements (in extra constancy check fields) are much faster than loops.
That is the problem! Give the user something to see that there is still something in progress: You could implement a progressbar in your “big warning”.
Here is a scheme I’ve come up with to achieve the results you are looking for. First thing is you have to create a new form to use for a modal dialog which will be used to prevent clicking to other windows or databases. Here is a test form I made that has three objects on it: a warning icon, a text label and an invisible button. The invisible button is to have a way of closing the dialog in case something goes wonky. Here is an image of that form with the code I added for the button that will close the window it it is pressed and the option key is held down.
Now here is the procedure that invokes the modal dialog and then either calls your testing procedure or can contain that procedure. After that procedure code is run it then would close the dialog window.
This is what the modal dialog looks like when activated. You can of course customize it as you would like including a progress bar as Kurt suggests.
Great idea Gary. I’ve always just tried to remember that things are happening and don’t touch the computer.
The next problem in need of a solution along these lines is the precarious time during an upload to an Enterprise Server. If things get touched during that process, a great deal of time can be lost as well as a bunch of work of deleting files / replacing files / manually downloading new files to users, etc. While these may not be an issue for Enterprise X, I’ve not found a solution for Enterprise 6.
Thanks Kurt. I believe that the procedure probably could be speeded up. It is only used once a month, so I have not invested the thought into doing that. The warning message is quite prominent so I it should adequately alert the user not to touch something. But a progressbar would be a nice addition.
Gary, that works perfectly. Exactly what I was hoping for. I only had to change two lines of my code. I need to learn more about rundialog; I had not thought of using that to disable other actions.
Just note that I did not use rundialog in this case - I used opendialog instead. I thought it would be the simplest implementation for allowing for all the code you wanted to execute while the dialog was open.
Yes, I meant opendialog not rundialog.
I have a couple of procedures that can take four or five hours to run and (as I’ve reported earlier) they will fail if I click in ANY window, not necessarily a Panorama X database. They also fail if the screen saver cuts in so I use Caffeine top stop that. My impression is that long-running Panorama X procedures effectively make my Mac a single-thread device.
That is puzzling to me and not what I would expect. I have definitely had procedures run in the background while I’m working in other programs. For example, whenever I do a release I need to run a very long procedure in my source database for the Panorama Help system, this takes at least 30 minutes. I can work on email, browse the web, etc. and Panorama X continues to work in the background. It also continues working when the screen saver kicks in.
Panorama X Server also runs in the background, basically by definition. In fact I’ve set it up so that it never has a visible window at all and can never be the frontmost application (and by default, doesn’t even have an icon in the dock). The server has reached a point where I’ve been doing a lot of internal testing, and it is definitely working in the background (which means running procedures in the background) in my tests.
That’s interesting because the procedures I refer to were written for my friend Orlando and he has experienced the exact same problem. The error message almost always relates to Panorama X not being able to execute a field statement.
Most likely none of the code I’ve ever run in the background has used a field statement. That gives me something to be investigated.
I have not observed the problem that Michael is describing. My testing procedure runs in the background, although slower. If I add a Field statement to the loop that is running, the procedure still runs in the background.