Progressalert created when database is not frontmost

I have a procedure which contains two very time-consuming loops, each taking several minutes when applied to the whole database. To reassure myself that it’s doing something rather than having crashed or entered an infinite loop, I set up a progress bar for each loop using progressalert.

These both work fine, and disappear correctly when cancelled at the end of each loop, provided the progress bar is the active window at the point the new progress bar is launched in the second loop.

However, if I know I’ve got time to kill and can keep half an eye on how long I’ve got, I’ll probably switch to Safari, Mail or another application to do something else while it’s getting on with it. If another application is active when the new progress bar starts, instead of creating a single window, Panorama launches multiple identical progress bar windows, stacked on top of each other with an increasingly heavy shadow. These can be moved around, but when that second progress bar is cancelled, only the frontmost of the windows is closed. Then, because there is still at least one progress bar window open, Panorama naturally behaves as if it hasn’t been correctly cancelled and, as the help page states, ‘the progress alert will be stuck and you’ll have to force quit Panorama.’

This screenshot shows just six progress bars that were created when running the second loop using a small subset of the database:

When running the two loops over the entire database, where the second loop would take more than ten minutes, the stack of progress bars is much deeper. Here I have moved the top seven away from the stack but the heavy shadow suggests there’s a huge number left below the middle one.

I would suggest using the setbannerprogressbar statement. This displays the progress without having to open a separate window.

When the Progress Bars do get left on the screen, there’s closeallasyncprogresswindows to close them.

And, as of April last year, the Progress menu contains just one item, a command to close all visible progress windows.

Actually, no. This statement will close all asynchronous progress windows, which are created by the openasyncprogresswindow statement. The progressalert statement Peter used is a separate feature, not asynchronous. So the dialogs created by progressalert won’t be affected by closeallasyncprogresswindows.

I do have on additional thought - you might try turning on the sheet option when using progressalert. That opens the alert window as a sheet attached to the current window. Maybe that will work even if Panorama is in the background. Maybe. The problem is, the macOS API’s handle windows differently when the app is not in the foreground. Some operations just won’t work in the background - Apple really didn’t set up the macOS API’s with the idea that apps would be autonomously performing window management tasks in the background. In general, apps don’t perform tasks like opening windows unless they are in the foreground.