Hello Everybody,
PanX seems to have difficulty knowing what database is THE active database. I bet this is partly to blame for single-stepping misbehavior.
Try this.
Create two databases - “DB A” and “DB B”. Leave them open.
Copy and run this macro in DB A:
setactivedatabase "DB B"
closedatabase "DB B"
message info("databasename")
RTN
Vic
The setactivedatabase command is unnecessary here. You don’t need to make the database active to close it with a closedatabase command. Without that first line, the message statement has no problem naming the correct database.
Dave, the point of the example is that when one of two databases closes, the remaining database should become the active database. That’s how Pan6 works.
With PanX, this is not the case.
I have a database which opens another database, extracts some data with an arrayselectedbuild command, AND THEN CLOSES THAT DATABASE. But the next code line, which refers to a field in the still-open database, gives me an error, saying “there is no such field as …”. But that field DOES exist in the remaining database. It didn’t exist in the closed database. But PanX was looking for that field in that closed database.
It seems to me that PanX has some difficulty knowing what is the REAL active database. That is what my example was meant to show.
By the way, my trouble macros are direct from Pan6, which had no problem keeping the databases straight. Same macro, but never got an error message saying no such field exists in the still open database.
Vic
The problem seems to occur when closing a background window changes the active database. If we close a database that is active in a secret window, we have the problem. If we close a database that is active in a visible window, it seems to work correctly.
If I add wait 0 to the example code like this
setactivedatabase "DB B"
closedatabase "DB B"
wait 0
message info("databasename")
RTN
it also works correctly.
?? Not sure I understand. I close an open database (and obviously its window). The next code line refers to a field in the still-open database.
So why does PanX think there is no such field in the still-open database. Why does it stop the macro and give me an error?
I’m just trying to narrow it down for diagnostic purposes. If Jim knows when the problem occurs, and when it doesn’t, it may help him to track it down and fix it.
OK.
Jim, it’s hard enough to track down macro errors. Kudos to you for being able to track down PanX errors.
This code is definitely not “direct from Pan6” – the two statements you have used (setactivedatabase and closedatabase) did not exist in Panorama 6. You claim it’s the same macro unmodified from Panorama 6, but it cannot be.
It’s not just necessary, it’s counterproductive. The whole point of the (new in PanX) closedatabase statement is that you don’t need to make the database active just to close it.
I find this kind of general rhetoric to be very inflammatory. There is a minor bug in the closedatabase statement when it is used in a a specific (and unintended) way. You’ve inflated that to “Panorama doesn’t know what the active database is,” which to me sounds like Panorama is wandering around drunk looking for the active database.
You lose that bet. Has nothing to do with it. There is not “one thing” that is the problem as far as single stepping goes.
Hello Jim,
It is most definitely not my intention to have a disagreement with you about Panorama. I would certainly lose such an argument, and would feel terrible being on opposite sides.
When I said the code is direct from Pan6, I didn’t mean the nomenclature was identical. I meant the functionality was identical. In Pan6 I opened a file with openfile, closed it with closefile, and then had the next line of code refer to a field in the remaining database. Pan6 found the field and continued. In my PanX version, I just replaced closefile with closedatabase. PanX could not find the field I referenced, stopped, and gave me an error. Nothing else substantive had changed.
As for the redundant and counterproductive setactivedatabase command, I only used that for my simple example to show what was happening. In my macro, I didn’t have a setactivedatabase command. Opening the new database and manipulating it before the arrayselectedbuild assured that the database was active. But after that database was closed (with closedatabase), PanX was unable to find the next field I referenced, apparently because it was looking in the just-closed database.
My language might have seemed inflammatory, but that was unintended. My wish is for PanX to be successful and widely used - especially by me, a long-term user dating from Overvue days.
You indicated there is a minor bug in closedatabase command. Is there a recommended workaround in the meanwhile? For my macro, when I get back to it, my intention is to use setactivedatabase on the current database, just to make sure PanX knows which database to look for other Field references. Is that a sound approach?
Best regards,
Vic
Why did you do that? The closefile statement is available in Panorama X. As it turns out, apparently the closefile statement has the same problem, so you would have run into the problem anyway.
For future reference, if you say “macros are direct from Pan6” and “same macro”, I’m going to interpret that as the code being actually identical. Code is very literal.
Did you try Dave’s workaround of using the wait 0 statement?
If you still have a problem, try these additional two lines.
closedatabase ...
wait 0
setactivedatabase ""
Hello Jim,
Thanks for your suggested code. I’ll give it a try.
But I’m surprised that no one else has had this problem before me. Haven’t the experts in the forum (Dave, Gary, et al) had occasion to close an active database, when two or more are open? What method do they use to close the active database?
I do this all the time in Pan6. I open an outside database, extract data to a variable with arrayselectedbuild, and immediately close the outside database to keep it “safe” So I really need to have a foolproof method in PanX. Your suggested code might be just the ticket.
Query: should the closedatabase command only be used for a non-active database, to avoid further problems?
Best regards,
Vic
In most cases, the active database is in the active window, and there isn’t any problem with closing that database. The problem you are describing occurs when the front window is not the active database. Closing the active database under those exact conditions just isn’t that common.