I’m having trouble closing a window with closewindow in a procedure if the user clicks away from PanX before the statement is executed.
I get the following error message:
I hoped magicforwindow could help in this situation, but it didn’t.
Adding to this report, if I click away from PanX and then click back on any PanX window (returning focus to PanX) before the closewindow statement is executed, the error message is still generated.
I believe this is because the closewindow command stops a procedure from continuing. There was something like this in conjunction with the print dialog. You can search for that topic here.
I’m guessing it stops if the closed window is the last visible window in the database running the procedure, I have not confirmed this. In my case, closewindow is closing a second open window in the same database, leaving the database still open to complete the procedure.
Actually the procedure will continue to run even if the database that contains it closes. The Procedure will run to conclusion unless there is an error or Panorama X itself quits. I just confirmed this with this code on a test database:
closefile
wait 10
message "OK"
Sure enough, 10 seconds after closing the file the message popped up.
I actually think this is working exactly as intended. The documentation says:
This statement closes the currently active window.
When Panorama is not the frontmost application, there is no currently active window. Only the frontmost application can have a currently active window. I’m sure you were thinking whatever the frontmost Panorama window was was the active window, but that’s not the case.
Yes, that won’t help because it only works within Panorama, it can’t affect the fact that Panorama is not the frontmost application.
You may want to use info(“panoramaisactive”) to check if Panorama is active. That way you could give a different error, or you could use bringpanoramaforward.
Jim, unfortunately, bringpanoramaforward didn’t work, and the error message is still generated.
This is how I used it:
openform "Test"
delay 3
bringpanoramaforward
closewindow
If I activate the desktop while the delay is happening, the error message appears.
How about using an AppleScript to make sure Panorama is brought forward.
openform "Test"
delay 10
applescript {
tell application "Panorama X"
activate
end tell}
openform "Test"
closewindow
Note that the last openform is to make sure the “Test” form is the one brought forward to be closed.
That did it Gary! Part of the trick is the second openform “Test” that you added. Without it, the error message still shows up, instead of closing which ever form is front most.
Then I tried the following, but still doesn’t work:
openform "Test"
delay 3
bringpanoramaforward
openform "Test"
closewindow
Thank you for the workaround.
Had a thought that it might be wise to change the AppleScript to get the name of the current Panorama X application in case more than one version is currently running.
applescript {
tell application }+quoted(info("panoramaname"))+{
activate
end tell}
Of course if Apple ever decides to deep-six AppleScript we are back to square one. 
I’m glad to hear it. But I’m also puzzled, because I would have assumed that the bringpanoramaforward statement uses the same API that AppleScript uses when you activate. Perhaps I’m not correct about that assumption.
I later tried the exact same code but using bringpanoramaforward instead of the AppleScript and it worked for me without an error. Don’t know why one worked for Hugo and the other did not.
Were you able to confirm that you saw an error with Hugo’s original code? I think he is using shared databases so that may be required to see the error.
I just ran this earlier code:
openform "Test"
delay 3
bringpanoramaforward
closewindow
I got a CloseWindow error when I left Panorama X before the last two lines executed but the procedure window was brought forward so the bringpanoramaforward statement evidently executed ok. Also got the error when I substituted the AppleScript in the above code. If I add the second openform statement before the closewindow statement I do not get a error using either th AppleScript or the bringpanoramaforward method.
Thanks @gary for the clarification, that is helpful.
I double checked and confirmed that the above doesn’t work for me, I get the error message and Gary doesn’t. I’m testing this in Mojave 10.14.6.
Not in this case. I’m reproducing the problem in a brand new, one record, one field database with a couple of forms.
I’m using Monterey 12.6.
More than a year later I have been having exactly the same problem trying to close a window without an error while another application was foremost, until I found this thread.
I was certainly under the impression that closewindow would close Panorama‘s currently active window, and didn‘t consider that it might matter whether Panorama X was the foremost application at the time. macOS is a multitasking operating system, after all! But bringpanoramaforward seems to be the answer.
This works for me: using rememberwindow immediately after opening the window in question, then
bringpanoramaforward
originalwindow
closewindow
to close it.
I have suggested an addition to the closewindow documentation to stop me and others falling into the same trap in future.
(macOS 13.5.2; Panorama X 10.2.0.b38)
. . . However — and this is weird — neither bringpanoramaforward nor the equivalent Applescript (in Gary‘s post above) work when the current active application is Safari (17.4.1). If it‘s Mail, Preview, Messages, Finder, TextMate, Firefox or Chrome (for instance) the solution in my previous post works perfectly, making Panorama X active before making the original window active and closing it, but not if it’s Safari. That’s annoying, because I’m most likely to while away the time while a slow procedure runs by surfing using Safari!
It‘s clearly not a Panorama X bug, but another of those annoying Apple inconsistencies…
If only there were a simple statement such as
closewindow database, windowname
and/or
closewindow windownumber
to close any Panorama window, in the background if necessary, without having to ensure that it, its parent database and Panorama are all active first. I assume this is a limitation of the way macOS handles application windows.