I can repeat this at will with new databases containing nothing but a .Initialize procedure. If the .Init contains an opensecret statement and a setactivedatabase statement, followed by a letfileglobal statement followed by several messages statements as below:
… and I open the file after quitting Panorama X, I consistently get the error message shown above. This never appears as an alert, the procedure just stops after the first message - I got this image by using the run button in .Initialize. Using let instead of letfileglobal, the three messages display.
Opening a different file secretly produces the same result. Removing the closefile statement makes no difference but removing either of the opensecret or setactivedatabase statements gets rid of the problem.
Just looking at it, I wonder if it is some confusion of what the active database is. What if you add setactivedatabase “OriginalDatabase” (or whatever the database you are running this in is named) before the letfileglobal statement?
This is a heavily edited snippet out of a lengthy .Initialize procedure Bruce. I stripped it down to the bare minimum of statements that would exhibit the odd behaviour. i don’t believe that there is any doubt as what database is active at any stage in the original code. you could try your theory and see if it makes a difference
Bruce is correct on this account. I did an experiment and if you add setactivedatabase "" after the closefile statement everything works properly and all three message come up. The setactivedatabase "" statement makes sure that the focus is back on the original database.
Is this a bug or a feature? It would be easy enough, I suppose, for the closefile code to check whether the active database is still open, and to set it to the current database if it is not. That would perhaps be more natural than to have to set the current database in the procedure.
I get the same result as you, Michael.
If I add a statement alertsheet info(“databasename”) immediately after letfileglobal… statement, it returns of the name “Travel”. So Travel is not actually closed when the next step in the procedure is reached; the closing process has begun but not completed. I suspect that anything that puts some delay after the closefile statement will ensure that the file ‘Travel’ is fully closed before the next statement is executed.
as soon as I click to close the message dialog Panorama crashes. In this case I think it involves opening a modal window while a secret database is the active database. This crashes Panorama even if a simple alertnoyes window is opened.
There sure is. If I activate a database and close it, it’s axiomatic that Panorama X should assume that the next database down the stack is now the active one. I can’t believe that Panorama X does otherwise.
What’s happening in my example is that the contents of a variable is being displayed in a message statement and then, after I click the OK button, that same variable becomes unknown. That is decidedly weird behaviour and I’d dearly love to know how it’s happening…
?