Applying Initialize to the right file

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.

Local a,b,c,d
GetMaxWindow a,b,c,d
a = c-325

windowmenubar “basic -none”,""
Zoomwindow a,5,100,315,“noToolBar NoScroll”

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 should also work, but Gary’s way is simpler.

If dbcheckopen(“Addresses”)= 0
RememberWindow
OpenFile “Addresses”
If error
nop
else
window “Addresses:Secret”
call “.Initialize”
endif
OriginalWindow
EndIf

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:
Screen Shot 2022-07-14 at 11.43.24 AM

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.

Just ran into this again, in another file. Again, it’s when the OpenFile is triggered from a form in a Tab Panel.

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.

1 Like

What do you mean on the “wrong field”. Initialize doesn’t run on a specific field.

Maybe you mean the wrong file.

Yes, FILE is what I was referring to.

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.

Go Figure.

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.

Are you aware that you can now make it impossible for a user to close a file?

This is pretty recent so you may have missed it. In fact, maybe it isn’t documented? I know I covered it in the class though, and the release notes.