Database closes immediately after opening

I was going to start a topic about “does Pan X execute .Initialize on database startup like Pan 6 does” but I think this has morphed into another question. When I start up my “first” database, its .Initialize does a whole bunch of housework, defining variables and opening other files. Over to Pan X, nothing happens when I open the database. So I opened .Initialize to run it and see what happens. RIght off the bat it erred because the first file it tried to open hadn’t been moved over yet. So I moved it over, converted it and saved it. Ran .Initialize again and my database immediately disappears (crashed). Now when I try to open that database again it immediately crashes, which apparently answers my question: it DOES run .Initialize as usual. But I have a database that won’t open due to some conflict in the procedure. In Pan 6 I could use the Open Database wizard to prevent .Initialize from running, but I don’t see anything like that in Pan X. Is there something I can do about this?

And to complete my original question, does Pan X honor all of the “automatic” procedures like …ActivateForm, .Initialize and so forth as in earlier Pans?

You can run a one line procedure from another open database using only the openplain command. It opens a dialog to allow you to select the database to open. It then opens that file to the datasheet and does not run the .Initialize procedure.

Regarding the other question, Panorama only currently supports a couple of the automatic procedures. .Initialize is supported along with the new .PreInitialize which is basically to be used to set variables before any windows open. You should not have anything else in this procedure other than setting variables. The other automatic procedures are not yet implemented and some may never be as far as I could discern from some of Jim’s comments in the past.

thanks Gary, that let me open it, but I’m not getting very far. First off, whether it’s because I’m in a special mode or just lucky, I’m getting the beachball every time I try to click on something (again) and it’s very difficult to get anything going. But the debug tools (Run, Step) don’t do much useful. Step accomplishes nothing, and Run will work once; it takes me to the first debug statement and neither button will do anything after that. It’s making it very difficult to find where my problem is.

It is very hard to tell whether clicking on something is being ignored, taking an unusually long time, or …? This is being a very difficult development environment for me.

See Bitbucket Issue #295. This is an early release and still some distance from final release. I can only say that things have steadily improved over the time I have been working with it.

My normal trouble shooting method is to use what I call floating stops instead of the normal debugging tools (I even did this in Classic Panorama as well.) I simply put a stop command at some point in the code before the area I suspect is causing problems. If the code works up to that point I them successively start moving the stop further and further down the code until the problem shows up.

Another debugging process is to insert messages to show how far it’s getting or the value of a variable.

Some code…
Message "1"
More code…
Message "2"
more code…
Message SomeVariable

Thanks for reminding me of various other approaches to debugging. I used the Message “” method to track my progress through my procedure and may have discovered a subtle difference between 6 and X, and/or I’ve forgotten some of the fundamentals I’ve had no need to think of for a while.

My .Initialize procedure opens a bunch of other files through its progress, some briefly and some remain active, either visible or invisible. The very first file I open is one I only need to extract some info from and then close it. All the manipulation of this file (opensecret, do stuff, close it) happens in another procedure called from Init. What is happening is that the last command in this file, CloseFile, is NOT closing the file that I have opened secret and no longer need, it is closing the file of the calling procedure which is my main database. No surprise that it suddenly disappears! Not a crash at all, just following orders. But in Pan 6 closing my secretly opened file does not do this. Can anyone explain this? There is no harm in leaving my secret file open, but I need to know what to expect as I struggle through this.

I think I need to adjust my expectations, and realize Pan X is not ready for action. There is much to learn! Very interesting, though.

I reported this as issue #524 on Bitbucket.


That’s going to be a bit tricky to fix. Right now the code sends a close file message to Cocoa, and of course Cocoa only knows about visible windows. So I’ll need to add alternate code that works completely differently for invisible databases. I’m sure it can be managed, but it’s for sure not going to be a one line fix.

Here’s my workaround for closing a secret file:

if info("files") contains "SecretDB"
setactivedatabase "SecretDB"
openform "Tiny"

Tiny is a small form with a goodbye message. Since you are just starting, you might try “Fired up. Ready to go.” Or you could open Tiny outside the visible screen area, and never see it flash by.

You could also try:

openform "Tiny"```

This opens the "Tiny" window in a 1 x 1 pixel window in the top left of the screen under the menu bar. Totally invisible except the current active form will flash inactive and then active for a  second. This trick goes back to the days before Panorama supported secret windows and folks had to try and open the fake secret window somewhere far off screen.

This bug has been fixed. The fix will be in the next release of Panorama X.

A few new questions get raised in the process.

In this thread I see Jim first saying this will be a complex thing to fix, then further down saying “this bug has been fixed.” Are we talking about the same bug?

I was pretty sure I started this thread in the mode that would notify me when there were replies, but I happened in here this morning to see half a dozen responses that I was unaware of. Am I missing something?

Do we get notified automatically when a new release comes out?

I’ve discovered another artifact of this problem. By commenting out my CloseFile command (the one that should have closed the current secret file but instead closes the one with the active procedure running) the context of the continuing code in the calling procedure is no longer that file, and fileglobal variables that were initialized in the calling procedure are not recognized. While waiting for the fix, is there a way I can work around this for now? I’ve considered doing a fresh OpenFile of my original file, but I’m afraid it will start my .Initialize procedure over from the beginning, rather than where I left off.

Also, I have a programming truism: programmers are a programmers worst nightmare! We are the ones who don’t really need to RTFM, we write them! I have, and no doubt will continue to, asked questions that have already been addressed in videos and other training materials. Apologies in advance for the inevitable next times, it seems to be how I roll.

Are you familiar with RememberWindow and OriginalWindow? They’d be very useful in your situation, with or without CloseWindow.

Yep, same bug. I actually completely rewrote the closefile code.[quote=“staylor246, post:12, topic:209”]

Do we get notified automatically when a new release comes out?

Once a new release comes out, the next time you launch Panorama X you’ll be notified and asked if you want to update now. You can also check at any time with the Check for Updates option. If you say yes, Panorama will automatically download the new version and relaunch Panorama X.

James -I have used them before, a little bit, but don’t think about it usually. And I wouldn’t have thought of it now because it’s not a “window” issue as much as a “file” issue and I wouldn’t have thought it would apply here. But it did the job! It gets me further through my procedure, far enough to encounter some currently unsupported stuff that will require other solutions. I probably need to take a break from beating this poor horse.

Funny (?), I did the remember/original wrap around another opensecret section, which is followed by a “window ‘MyMainWindow’ show” command to refresh my main window with information I got from the secret file, and it tells me that window doesn’t exist. It’s the window I’m in! I probably reached the “too many workarounds” limit.

Curious about Jim having fixed the closefile code - will we see the update soon? I’m not familiar with the timelines of such events.

The window statement needs the full window name which includes the database name, a colon and the form name: window "MyDatabase:MyForm". Also note that the show statement has been replaced by the endnoshow followed by the showpage statement (even though it has been retained for compatibility). The same holds true for the hide statement that now is preferred to be the noshow statement.

I’m having more issues with (almost) the same problem. I restored the called procedure (subroutine) to its original code, since CloseFile in a Secret window has been “fixed.” Here is the basic program flow:

Open Main database
Automatically run .Initialize
define several global and fileglobal variables.
call SetDefaults (my secret subroutine, which does the following:)
OpenSecret “Defaults” (panx file)
Loop [do stuff] Until stopped
CloseFile (to return to calling Main database)
** error ** variable does not exist [trying to assign a value to one of the fileglobal variables defined in Main]

Sounds like we still have that secret file open and we’re not in the Main fileglobal context.

So I put a couple of Message statements before and after CloseFile:

message "Leaving SetDefaults " + info("files")
message "Left SetDefaults " + info("files")

The result? Both messages show the same 2 files open: Main and SetDefaults, even after the CloseFile command. But now that the messages are in there, when the CloseFile command is executed, the screen goes blank, leaving only my second message box on the screen. I click OK and we’re done (way prematurely). If I look to see what Windows are open now, there are none.

Maybe I’m missing something…

I think that you are thinking that Defaults becomes the active database after the opensecret statement.

OpenSecret "Defaults"
Loop [do stuff] Until stopped

It doesn’t, in either Panorama 6 or Panorama X. Your main database is still active. So both the loop and the closefile apply to the Main database, not the Defaults database.

Here is a corrected version:

OpenSecret "Defaults"
setactivedatabase "Defaults"
Loop [do stuff] Until stopped

The second line, setactivedatabase, is equivalent to

window "Defaults:SECRET"

which would also work.

One other point – in Panorama X, using a message statement will cancel any secret window, restoring the top visible window as the active window. I’m not sure if that is true for Panorama 6. So in a situation like this, it would be better to use the nsnotify statement instead of the message statement.

In pursuit of simplifying my post, I left out the fact that I do indeed have window “Defaults:secret” right where it should be in the code, so that is already covered. I was not aware of the interaction of the message statement but I have previously wondered why putting in a diagnostic message like that sometimes gave me weird results.

I gather nsnotify is a new X command, I don’t find it in 6. I’ll try that. When you say message “cancels” a secret window, what does that exactly mean? My messages showed both files still open after CloseFile, but they had both apparently closed anyway, since nothing was left on the screen except my message dialog. And strangely, my original calling procedure (.Initialize) continued to run, because I got a prompt following that from that procedure. Then it all died.

Anyway, I will try this method and see what I get. “setactivedatabase” might be a good tool to use in a number of places.