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


#1

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"
closefile

Does somebody please verify this?


#2

Did you try the opensavedwindows statement?

So this program should do it:

setactivedatabase "Miscellaneous categories"
opensavedwindows

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

setactivedatabase "Miscellaneous categories"
opensheet

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

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

#3

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.


#4

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.


#5

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"
closefile
openfile "beta"
opensheet

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.


#6

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


#7

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.


#8

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.


#9

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.


#10

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:

loop
    nop
until 10000000

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