In a procedure that checks to see if a reference database is open, I’m using this simple process:
If dbcheckopen(“Addresses”)= 0
RememberWindow
OpenFile “Addresses”
If Error nop EndIf
OriginalWindow
EndIf
If the reference file is not open, it’s being opened, but its .Initialize procedure (below) is then run on the calling file. I can’t seem to prevent this. The window is resized and the menubar is revised.
Adding the file and window names to the file’s .Initialize have no effect. Moving the RememberWindow and OriginalWindow to the start and end of the original procedure have no effect either.
I’ve tried numerous variations but cannot get the original file to remain as it was if the opening file has an .Initialize procedure.
I can do away with the window sizing since the Database Options now cover that.
Using Form Event for the second db still applies everything to the first file…
I would try using the opendatabase statement instead of the older openfile. This statement handles the .Initialize as you would want it handled in this situation. This is from the Help file for the opendatabase statement:
Custom Database Initialization
If the database contains a procedure named .Initialize , that procedure will run before any code >following the opendatabase statement.
This isn’t going to make any difference. You can look at the source code of the openfile statement, you’ll see that it actually uses opendatabase to open the file.
Is not.
I took the time to create two new databases, I literally copied the code from your post above and used it unmodified in my databases. Works the way you intended every time.
After working a lot harder on this, I can add more info as well as more mystery.
There is no more or less code involved than what I posted,
The procedure is triggered by a tab on a Tab Panel and does the same if other closed files are opened. I checked carefully and after making sure no form actions were involved in the Tab Panels, the host form or the file being opened, it continues even with a STOP following the OriginalWindow.
Sometimes, this notification comes up:
If I run the procedure directly or trigger it with an independent button, it works as it should. So somehow, the fact that it’s being called by a Tab Panel would seem to be the difference.
I eliminated everything else associated with the tab panel and made sure there were no other actions connected, but could not change the result.
I created a new form and added a simple Tab Panel with a different variable for the Data but had it call the same procedure. Once again, the form containing the Tab Panel had its size and menus conform to those defined in the Initialize procedure of the file being opened.
This remains an issue and I don’t see that it ever made it to BitBucket.
OpenFile triggered from within a TabPanel causes the Initialize to run on the wrong field. As a result numerous other errors are possible and it may require a full Quit in order to correct or avoid them.
I seem to have resolved this specific issue. By starting the procedure with a ShowVariables and the name of the Tab Panel’s variable in the Tab Panel Options, the whole issue of the Initialize effecting the wrong file is eliminated.
I think this actually makes sense. The showvariables statement causes Panorama to briefly pause to update the UI. This gives the tab panel a chance to update before you start switching windows behind it’s back. You might also have been able to fix this by adding a wait 0 statement before opening the second file.
For what it’s worth, opening a second file when switching tab panels seems to be a very questionable user interface to me. User interface elements shouldn’t surprise the user, and I would be very surprised as a user if I saw this happen. I’m clicking to see another tab panel – the last thing I expect is for a different file to pop open.
Agreed and ideally, the formerly Auxiliary files were opened as small forms in the background for reference. Typically they’re used for Relations within the Tab Panels. In the event that the user happened to close one or more of them they need to be re-opened when the Tab Panel is accessed or the relationships don’t work. Secret windows didn’t fit because there are occasions when the user may need to directly access them to edit a relationship.
Hmmm, I did miss that one. It’s possible I missed that class or that other new features caught my eye and attention. I would like to know more about it though since it does appear to be what the doctor ordered in many cases.
I think it was covered in the 2nd video course from May 2022.
Basically if this option is enabled, if the user closes the window the database stays open as a secret database. Of course you can open windows later if needed, but the data is always available for lookups, etc.
Yup, the one that I missed. I was in on one and three. It’s now available so I need to view it. They’ve been very helpful in learning all of the many ongoing additions to Panorama.
