Openfile won't open a d/b previously opened with opensecret but not closed


In Panorama 6.0, I could open a file with opensecret, leave it open and open it for visual inspection at any later time with openfile. This is not the case in Panorama X. If a secretly-opened file has not been programmatically closed, it is impossible to open it conventionally. I have to resort to running a procedure which does this:

opensecret "Miscellaneous categories"
setactivedatabase "Miscellaneous categories"

Does somebody please verify this?


Did you try the opensavedwindows statement?

So this program should do it:

setactivedatabase "Miscellaneous categories"

You can also open a specific window, for example the data sheet

setactivedatabase "Miscellaneous categories"

Or a specific form, in which case the setactivedatabase statement isn’t required.

openform "Report","Database","Miscellaneous categories"


I cannot verify this. This was a bug in an earlier version of Panorama X, but was fixed quite some time ago (I think around a year ago). In fact, I think that is how the opensavedwindows command mentioned above got created – the openfile statement uses that statement to open the windows if the file is opened secretly.


You’re saying that yu can open a file with opensecret, exit the procedure without closing that file and then re-open it conventionally? I certainly can’t.


To elaborate - I download the new zip file from the ProVUE website, restart my Mac and quit all open applications. I expand the zip file, put Panorama in the Applications folder and use File->New to create two new databases, alpha and beta. In alpha, I put this procedure:

opensecret "beta"
setactivedatabase "beta"
openfile "beta"

Every time I run it, beta opens OK but, when I close beta, Panorama crashes, as in quits unexpectedly. Saving beta has the same result. Putting data into the fields of the two databases before closing beta makes no difference.

If I comment out the closefile statement, it’s happy and I can open and close both databases manually as often as I like.

I would dearly love to know what’s happening so I can get on with writing my system.


I get the same result. When I close beta after this sequence, Panorama crashes.
If I drop the first three lines and just open beta, then there is no problem closing beta.
If I insert an alertsheet “hello” after the closefile, so that after acknowledging the alert, beta opens, then beta will close normally.
I have a theory, from someone who does really know what goes under at a low level, that the closefile operation takes some time and it is not finished when the openfile statement begins trying to open the same file that is not finished closing. I think I have offer such a theory in similar situations


I have experienced numerous odd behaviours by Panorama X that suggest that one action is initiated before a prior action has completed, sometimes with unfortunate results.


It might seem, at first glance, that my alpha/beta results are contrary to my initially reported problem. Not so. The initial problem related to opening a file secretly and then exiting the procedure without closing it. In that case, I could not subsequently open the file by any conventional means. This is still the case with the alpha/beta example - if I comment out the last three statements and run the procedure, I cannot then open beta by double-clicking on it - the file icon “quivers” but remains un-openable until I quit Panorama or run a procedure as described.

I think Jim’s solutions were targeted at opening the file from within the same procedure that ran the opensecret - that was not relevant to my problem.

I guess I’ll just have to stop using opensecret.


Michael, it sounds to me that your definition of “open” is imprecise. Opensecret had left the file open in memory without any open windows. It seems that you are expecting a finder double-click, etc., to open a window you’re used to seeing with that file, either a form or its datasheet. Instead the finder double-click leaves the file open with its currently displayed windows, none. That is the same behavior I’d expect when double-clicking an already utility application which normally operate via windowless Dock or Menubar interfaces: no open windows, but other interface clues show they are, still, open. Maybe Pan6 opensecret files responded differently to being opened in the Finder, I’ve forgotten, but I think this is the proper behavior. The Finder shouldn’t override explicit directions within PanoramaX for a file to have no open window.

You can verify the file is open a variety of ways. it is listed in the View Organizer popup from which you can open a form or procedure window therein. You can open its datasheet via OpenView, when the all databases option is selected there. You can access the previously opensecret, not closed, file in a later procedure without first re-opening it. Secretly open files always have shown up on the Memory Usage dialog. Jim took my suggestion (thanks, Jim!) and added a popup menu there to open the datasheet on secretly open files.

Separately, I share your suspicion that closefile is asynchronous and sometimes causes problems by not finishing when PanX expects. I’ve never been able to find a consistent, straightforward enough, example to report; but coding delays at suitable points in my programs “to let things catch up” have resolved some bizarre issues for me. Based on what Jim has posted here previously I speculate an Apple problem is the cause.


I suspect you’re right on the money JB - Panorama 6.0 was probably breaking the rules and Panorama X doesn’t.

I thought so too, so I added this code after the closefile statement:

until 10000000

It induced a significant delay but did not resolve the problem so I can probably rule out that theory.