What Should PanX Close?

Hello Everybody,

I still struggle with the differences between Pan6 file behavior and PanX file behavior.

Can someone explain the following simple code? (Executed in a separate database)

Local f1, w1
openfile "~/Data/Macros/AA Test"
    f1 = info("databasename")
    w1 = info("windowname")
//  message f1
makesecret
setactivedatabase f1
closefile
message info("files")

RTN

When this code runs, BOTH the calling and the called files are listed in the message window. So apparently the closefile command didn’t close anything.

The only way I can figure this out is that PanX cannot CLOSEFILE a secret file! If so, is the reasoning that the secret file will automatically close and disappear when any other window opens? But then, what happens if one opens several secret windows? Do they all remain in memory until you return to the calling datasheet?

Vic

It looks like it takes a moment for the fact that the database has closed to register. If you put a short delay like

delay 0.1

between the closefile and the message, the message will only list the one file.

Hi Dave,

I tried that out, but it didn’t work. The message window still shows both. But knowing and trusting your acumen with things “Panoramic”, I experimented with the time delay. If you use delay 0.7, then it works! Only the remaining database is listed in the message window. Using “delay 0.6” or lower still results in both databases listed.

But the critical point is; is THE SECRET WINDOW IS REALLY CLOSED, regardless of the delay value? If so, then one doesn’t have to worry about the window hanging on. The user should just continue with his code, secure in the knowledge that everything is OK, and the secret window is really closed.

I will have to explore that further when I get some time. This whole issue may be simply a matter of PanX not observing as carefully or as quickly as it should. I can relate to that!

Vic

Hello Dave,

Did some more experimenting.

I can confirm that neither the closefile command nor the closedatabase command actually closes a secret file. Apparently the secret file closes on its own ONLY after a new window, such as a message window, opens.

In the first code example below, the “message t1” window opens and shows the correct values from Field “Test” in database “AA Test”. But the next line (Field «Test») is interrupted by PanX with the message that no such field exists. So at that point, “AA Test” closes.

However, if you un-comment the “message info(“files”)” command, then it executes showing BOTH databases, but the very next line is interrupted with the error no such field exists.

It is the opening of a message window that clears PanX memory of a secret window. The closefile commands do nothing.

Local t1, f1
openfile "~/Data/Macros/AA Test"
    f1 = info("databasename")
makesecret
setactivedatabase f1
ARRAYBUILD t1, ¶,"",«Test»
closefile
closedatabase f1

// message info("files")
Field «Test»
ARRAYBUILD t1, ¶,"",«Test»
message t1
Field «Test»

RTN

This is very different, and not as intuitive, as the Pan6 method to close a secret database:

// THIS IS THE PAN6 CODE TO CLOSE ANY SECRET WINDOW
Window "my file:SECRET"
closefile

Jim, is there a PanX version of the above simple Pan6 code which accomplishes the same thing? By the way, the above code does not work in PanX.

Perhaps eschewing secret windows in PanX is a way to avoid these issues. The feature-rich environment of PanX has more than enough goodies to satisfy all of us.

Vic

Here is the simple way to perform this task:

opensecret "~/Data/Macros/AA Test"
let t1 = arraybuild(cr(),"AA Test","Test")
closedatabase "AA Test"

I tested this out, it works. The local variable t1 contains the data at the end, and the AA Test database is closed.

OK, Jim.

So it is the use of the arraybuild FUNCTION, and not the COMMAND that resolves the issue. Actually, in Pan 6 I never used the function method. I always used the arraybuild command. Is that command not recommended in PanX? Is this something that can be corrected in PanX code in an upcoming update?

On an unrelated observation:

In an earlier post, I remember you writing that the increased “overhead” in PanX means that it might be slower than Pan6. I do notice slower behavior when doing routine things like sorting, grouping, selecting, etc. But my impression when performing calculations within a procedure is that PanX is FASTER that Pan6. Or perhaps just as fast. It is certainly not slower.

Is my impression correct? I haven’t bothered to measure the difference.

Vic

Incorrect. You could use the statement instead of the function if you prefer that. It’s really just a matter of personal preference.

opensecret "~/Data/Macros/AA Test"
local t1
arraybuild t1,cr(),"AA Test",Test
closedatabase "AA Test"

The way I resolved the issue was simply by using the opensecret statement instead of opening the file visibly and then making it secret.

Hello Jim,

Yes, I see that.

In my current project to convert a Pan6 DB to PanX, I want to open a file as normal, but later to “make” it secret. I won’t know the name of the particular file beforehand (an earlier loop chooses the file). What is the preferred method of closing a file that has been “made” secret by the “Make Secret” command?

Vic

This has nothing to do with anything. I’m sure you’ll have the name of the file in a variable, so you do know the name of the file. (If you didn’t know the name, you couldn’t close it, full stop).

There are two methods you could use - either the closedatabase statement or setactivedatabase followed by closefile. I would say that closedatabase is simpler, but ultimately there should be no difference between these methods.

I’m wondering why you even care. Do you have huge secret databases and limited RAM in your computer? And by huge I mean a gigabyte or more? If your file was only 100 megabytes (and I’ll bet it is much smaller) there is really no drawback to just leaving it open until you are done with Panorama. It’s 2023, your computer has plenty of memory.

I appreciate that attitude Jim as I currently have 18 databases open. It is just what works well for me. I’ve wondered whether I should be reconsiderating what seems to work just fine.

1 Like