Understanding Secret Windows

I’m late to the world of Secret Windows as I’ve typically found issues with them but as I’m trying again to make use of them, I have a question or two.

Using the feature of Auxiliary files, I have other secondary db files opening with no windows. When I close the primary db though, they obviously remain open in memory. How is a user to be aware that there are dbs open that are not seen nor are in the Windows menu? What is the proper way to manage this detritus?

When I open the primary db and then secondary dbs open before the .initialization procedure of the primary db is run, I am left with many lookups on the primary not displaying their values that were dependent on the seondary dbs being open. I thought perhaps a ‘DesignMode DataMode’ procedure might be the appropriate way to ‘update’ the primary db but that would have happened in the .initializtion procedure. How would that best be handled.

In the old ways, I’d just open the secondary files first so that the primary file being opened last would automatically have the secondary files open and the lookups would automatically take care of themselves.

I’ve used secret databases constantly since day one. I still open secret databases from the primary db’s .initialize procedure and call their .initialize procedure, if any, then head back to the primary to finish its run.

I haven’t tried using Auxilary files yet, cause if it ain’t broke…

And if someone closes the primary via the red Close button, are the secret dbs left open (secretly)?

They will remain open until you close them or you quit Panorama. They are not linked to the primary file (the file that may have opened them).

When I tested how this worked, with two other databases opened using the Database Options/Auxiliary function, the primary database opened, then ran its .Initilize procedure, then opened the first aux database, then Ran the first aux DB .Initialize procedure, then opened the second aux database, then ran the second aux DB .Initialize procedure.

If the aux DBs are opened without any windows, then their .Initialize procedures do not run automatically.

RE: the detritus. I am sure there are various approaches to managing databases that are open with no windows. In one case, I have put an X button the Home Screen of the main database, and it should be used to close the database. It has a procedure to close the aux databases then close itself, so those aux databases are not left open. Of course, users may ignore my X button and close with the red dot, and, as you say, the other databases are still open in memory. In that case, you could set up a timer when you start the main database and give it a global scope, Then it will continue running after the main database closes. The timer could periodically run code to check if the main database is not open; if not, then it would close the aux databases.

According to a previous post of Jim’s, the aux dbs are opened before the .Initialize of the primary db is run.

I’m still trying to figure out the easiest way to dermine what Secret dbs might be open. Yes, I’ve seen from the View Organizer that I can find them there. Just looking for the smart way to automatically close the secret when I close the primary or just continue to not use Secret windows. I do get that there is a place for secret dbs when others might too easily muck with them. I’m just using them for lookups so I was just trying to unclutter my screen. I typically have just kept them behind the primary but was wanting to be smarter about the use of secret dbs that have all these issues.

If you just want them out of the way, you could always open the auxiliary databases and zoom them very small, maybe even to a corner of the screen.

Yep, back to not using Secret windows. Seems that hassles of ‘secret’ should be reserved for when it is beneficial to keep things secret from users who might unknowingly muck with stuff that they shouldn’t be touching. If there is not that need, just position and size accordingly.

Using info(“files”) will show all open files including secret files. If you name them perhaps starting with a special character (“•” for example) you could use an arrayfilter to narrow the list to only the secret files that are open.

Appreciate that Gary. And for all that I see, I do appreciate that there is a place for secret windows when we don’t want the peons to see or touch important stuff. I guess I was hoping for a way to automate the minimize feature that Apple gave us which would not hide them from the Window menu and such but just get them far away from any distraction.

I continue to feel that secret windows have caused way too many problems with users not understanding which db is active and such, plus the ease of having them linger in memory and be open without any real easy way to be aware of them being open. (Obviously that would go against the marvelously named ‘secret’ window.). Nuff said. Appreciate all replies.

Robert, In Panorama 6, they were very easy to use and very useful. In Panorama X, not as much.

Well for the most part, who cares? So what if a tiny bit of memory is consumed?

However, these files are visible in the Memory Usage window. In that window you can make the database visible by right clicking on them.

What is the proper way to manage this detritus?

There currently is no automatic way to do this, but I have an idea for the future, see the BitBucket issue posted at the bottom of this message.

Tom’s description is exactly correct.

I don’t remember saying that, but if I did, I was mistaken.

Note: There is nothing to stop you from opening an additional file from your .Initialize procedure, just as was done as before. The auxiliary database feature is a convenience, you don’t have to use it if it doesn’t fit your needs.

How so? The feature works exactly the same as it did in Panorama 6.

Note: There are really two features here. One is a database with no visible windows. The other is the ability to make a database temporarily active even if it isn’t the topmost window, via a “secret” window. In retrospect, I really think the name “secret window” was a mistake, because there is no window at all. I wish I had never used this terminology. I no longer use the

window "database:secret"

idiom in my code, instead I always use

setactivedatabase "database"

which I think more clearly indicates what is going on.


This discussion has given me a couple of ideas for possible future enhancements to Panorama.

See thread titled “Breakthrough yesterday” as you may want to correct it there.

Secret windows work the same, but I can no longer control the closing of Panorama databases to manage them, so it’s not as good.

I don’t see that any correction is needed. That thread has the correct information:

Note: The auxiliary databases are opened after the .Initialize code runs, so code in .Initialize cannot rely on these databases already being open. If you need that, just use the opendatabase/opensecret statements as before.

I’ve looked high and low, but AppKit’s NSDocument class simply does not provide any mechanism to control the process of closing a document that I can find.

I’m you would if you could.