Active Database

Panorama X
1

Hello Everybody,

A not-so-subtle distinction between Pan6 behavior and PanX is how PanX treats the active database.

The following code in Pan6

FARCALL  "Various Macros", «myOpenFile», p1
message info("databasename")

will access the database “Various Macros” (which is already open), and run the myOpenFile macro. That macro opens the file p1. When the «myOpenFile» procedure ends and the original macro resumes (after the FARCALL command), the active database is the one newly opened. That is confirmed by the message statement.

But when that same code runs in PanX and the line after the FARCALL resumes, the active database is not the newly opened one. Instead, it is the database of the original macro. That too is confirmed by the message statement.

The actual database which is opened by the FARCALL command is not known for sure. It might be p1, but might not be p1 depending on other conditions, such as if p1 was already open. If that is the case, a copy of p1 is opened instead, and named “TempFile”.

In my Pan6 code, I immediately set a variable for the active database name after the FARCALL command, so that I can close that file when I’m done with it. But in PanX, setting that variable does me no good. Neither p1 nor TempFile is the active database.

I think the way Pan6 works is a better arrangement, Jim. For now, I will have to rely on a global variable, which I generally dislike doing.

Did I miss something?

Vic

2

Did you try setting setactivedatabase in the myOpenFile procedure?

3

Vic, you are mistaken. There is absolutely no difference between the way Panorama X and Panorama 6 handle the active database.

A common misconception is that the farcall affects the active database – it does not. The active database is always the database with the topmost window. It doesn’t matter what database is called by farcall, the active database doesn’t change.

The active database also doesn’t change when the code returns from a farcall statement.

Of course if is certainly possible that the code being called will change the active database. It sounds like your code contains an openfile statement – that will certainly change what database is active. It could also change from a window statement or a setactivedatabase statement.

Since you haven’t shown us the full code, I can’t explain the results you are describing. But I can tell you for absolute sure that Panorama 6 and Panorama X treat the active database EXACTLY the same.

4

Jim,

I’m sorry, but that is not so. Yes, the active database does not change when the subroutine ends, EXCEPT if you place a DEBUG statement in the code.

Here is the (very simplified) «myOpenFile» code in Various Macros:

Local f1
f1 = parameter(1)
openfile f1
RTN

Here is the calling code

Local t1
t1 = path+filename.pandb
FARCALL "Various Macros", «myOpenFile», t1
DEBUG
message info("databasename")
RTN

If you run this code without the DEBUG command, the message statement will return the newly opened database. But, if you include the DEBUG command, the active database changes. THIS IS DIFFERENT FROM Pan6.

The exact same code as above in Pan6 (except for the PanX extension) will ALWAYS return the newly opened database - with or without the DEBUG command. That DEBUG command was essential when I was writing, testing, and debugging my original code, so that I could tell which file actually opened (Tempfile or something else).

Pan6 and PanX do not treat the active database EXACTLY the same.

Vic

5

The debug statement stops the program. Stopping the program cancels any secret windows and makes the currently visible topmost window the active window. Because of this, you can’t use the debug statement in code that uses secret windows. This is true in Panorama X and was true in Panorama 6 also. There was some discussion of this on the QNA email discussion list a few years ago, though I don’t have time to find that discussion right now.

The code you posted above doesn’t use secret windows, but if the debug statement is having an effect on what the active database, I think the non-simplified version of your myOpenFile code must use secret windows (using the setactivedatabase statement will also do this, as it is equivalent to a secret window).

When you post simplified code, you are really blinding others on this forum, preventing them from giving you accurate help. Of course if your code is hundreds of lines long, that may be necessary, but whenever you simplify the code you post, you risk leaving out vital clues.

For example, I suspect there is an error in the code you have posted, which may have happened as you simplified the code in the process of posting it.

t1 = path+filename.pandb

This line doesn’t make sense, unless you have a variable named filename.pandb, which seems unlikely (in fact, I just verified that it is impossible, Panorama won’t allow a variable name with a period unless you surround it with chevrons).

Maybe the line is really this?

t1 = path+filename+".pandb"

If so, that makes me wonder what else might be different from your real code, which might be causing the issue you are seeing?

An unrelated issue, if this is the real code, the +".pandb" is unnecessary. The openfile statement will work just fine without the .pandb extension. For example

openfile "Invoices"

is just fine. You can also use this code, but it isn’t necessary.

openfile "Invoices.pandb"

In general, your code never needs the .pandb extension unless you are for some reason directly manipulating files on the disk, for example using the filetrash statement to delete a database, or using the fileinfo( function.

I think you must have added the +".pandb" code in your effort to convert to Panorama X. It’s ok that you did that, but if you have more code like this, you don’t need to make this change everywhere. Panorama X will work fine with the Panorama 6 code you already have.

6

Jim,

I think you are missing the forest for the trees.

Put the following code into a PanX macro:

Local t1
t1 = (enter a valid path and file name here)
openfile t1
debug    
message info("databasename")
RTN

Run the code without the debug command. The message will return the name of the newly opened file.

Run the code with the debug command. When you proceed from the debug step, the message will return the name of the current file - not the newly opened one. Pan6 with the above code does return the newly opened database name, with or without the debug command.

Secret windows, pandb extensions, simplified code, etc. have nothing to do with anything.

The whole reason for adding a DEBUG command is to freeze Panorama at a single point, take stock of the situation on screen, and then resume the macro from that exact point. If the debug command itself causes the active database to change, then subsequent steps will act on the wrong database.

Pan6 behaves properly.

PanX does not.

Vic

7

Ok, got it. I can make an even simpler example that demonstrates this problem.

window "Some Other Database"
debug
message info("databasename")

I think that older versions of Panorama used to have the same problem, but at some point, perhaps Panorama 5.5 or 6, it was fixed. Now I’ll need to make the same fix in Panorama X. I have added this to the bug tracker.