I have two windows: MainWindow and SettingsWindow. In the Opening event of MainWindow, I call a method to assign some values in the SettingsWindow to a dictionary. I’m not asking the SettingsWindow to open, but it’s opening anyways (assuming this is because the method is assigning its values. For example, in the method, some of the assignment statements look like this:
I’ve included a SettingsWindow.Close statement to get rid of the window in the method, but wonder why it’s opening in the first place when I’m only trying to get values/states from the controls in it?
An alternative design would simply be to leave ImplicitInstance on, and intentionally Open the settings window, but keep it Invisible (hidden) by setting Visible=false in the IDE:
This is a curious statement, and I wonder if your mental model is incorrect?
To get the value or state of a control, an instance of the control must exist.
For a control to exist, it must be located on a window instance.
Thus, trying to read (or set) the value of a control will either crash (if the window is Nil) or, if Window.ImplicitInstance = True, will create the window for you.
Implicit Instance is the kind of feature that is supposed to make things easier for beginners (at least I suppose that was the idea) but in reality achieves the opposite. When I started with Xojo, many years ago when it wasn’t yet Xojo, Implicit Instance bit me a couple of times until I started to switch it off for every window I created. These days I actually use it in rare cases, but then I know what I’m doing.
Implicit Instance tends to distort one’s mental model (like Mike suggested) as it muddies the distinction between a window that has just been defined and an instance of that window that has actually been opened.
Modify the Settings window to read and write from this class: in the SettingsWindow.Opening event, it reads the values and sets controls properly. In the .Closing event it does the opposite
Make an instance of the Settings class a property of the Application
In the Application’s Opening and Closing events, load and save the settings (to a text file, database, registry, etc.)
With this design, the Settings Data is decoupled from the Settings Window. A bit more work to set up at first, but much more flexible in the long run.
Mike D, yes I suspect my mental model is askew. I thought that once I create a window with controls in the IDE, I just need to show and hide it, and that its controls exist. But I suspect they don’t really exist (from a data perspective) until I create an instance of them by showing the window. Is that the correct way to describe it? If so, trying to access their properties requires they be created, resulting in the window showing.
I tried turning off ‘implicit instance’ for the SettingsWindow, but that resulted in many ‘item does not exist’ errors. Not going to do that.
I agree, the correct way to approach this is to get the settings properties from some persistent source, and then assign the values to the SettingsWindow when it opens, saving the updated values when it closes.
Also, I discovered that the dictionary I create in my method evaporated pretty quickly, so I’m needing to assign those values to a more persistent property (considering JSON as a property of the SettingsWindow, for use during runtime), and saving to file when opening and closing the application.
As @Mike_D suggested, assign your dictionary variable to a property (of type Dictionary) of the “App” object (type DesktopApplication) of your project.
The “App” object is global and persists for the life of your app. This is much simpler code-wise than wiring up JSON or some other storage method.
Or you could add a Module to your project and add your dictionary property there. Modules are also global and persistent. They are handy for putting functions and properties that can be called from any part of your app, similar to the “App” object (which is more like a class, whereas Modules do not need to be instantiated).
