Initialization order


There are many things that happen, or can happen, BEFORE the event is called
App.Open is NOT the FIST thing that runs.
In fact, App, which IS a METHOD not a class instance, can STILL return nil sometimes.

IF you NEED to make sure something IS 100% initialized before anything else, put a constructor on the App class in your project and use that
OR, as is suggested elsewhere, hide the details inside a computed property or method get/set pair that does a lazy initialization of whatever (whether you can use a computed property vs get/get methods is really determined by if you need to get/set an array or not - computed’s cant bet set with an array nor return arrays)

As an example, start a new desktop project
Add a constructor to App. And also add the open event.
For Window1, the default window, do the same
And we’ll even add our own menuitem as it too can run into the “App is nil issue”

In each simply put

System.debuglog CurrentMethodName + " app is " + If(app Is Nil, "nil", "not nil")

And then run
What you will see is

1:16:34 PM : My Application Launched
             App.Constructor app is nil
             Class1.Constructor app is nil
             App.Open app is not nil
             Window1.Constructor app is not nil
1:16:42 PM : My Application Ended

And this makes sense.
Somewhere deep in the bowels of the frame work it has to create an instance of our App Class
And that happens FIRST
But not the Window is NOT the next thing created
The menu bar, and all its items are

Heres a sample to play with

I have always assumed it was, so I always put initialization code there… I guess I have been lucky I have never been bitten by that!


1 Like

For a lot of average uses App.Open is “soon enough”
But there are times when it might not be
As the little sample app shows

My same thoughts.

Thank you Norman.

To add to your explanation is… bad luck (for example).

Also, been old does not help. I saw many issues when I was back home and the day after.

Before I rebuilt the project, I add code that feed the Month() array (located in a Module) in different .Open (Window, PopupMenu) and this does not worked. Obviously I have a problem.

All in all, I rebuild the whole project two times:

  1. I exported the windows and Modules to get the same troubles.

  2. I Copy / Pasted elements from Xojo 2021r2.1 into a blank Xojo 2015r1 project.
    In the process, I forgot many things and discovered plenty bugs [using Val(L.Text) instead of Str(L.ListIndex) does not help, but it was not the immediate faultive *]

I added a wMain (new) window with two buttons that display the windows where the Month() array with the correct Strings appears. I still have troubles and I think I have to wait until my brain will be at its max, then I will be able to see what wrong I’ve made in my coding or my design :wink: .

In the mean time, I will add preferences saving / reading; it probably will help.

Preferences folder locked on High Sierra: the Xojo file was not saved, and so the IDE continue to use its default Font and Size.

  • The PopupMenu was populated with blank lines, not with the wrong strings; populated with the wrong strings came later.

BTW: I loaded the project on a M1/Big Sur (for tests) and I saved the project (a bad idea, very bad idea, one of the worst ideas I ever had). This is the reason why I created a new project using Copy / Paste.

Back to the original subject.

I created a simple project, then report the code into the main project.

In doing so, I forgot a line of code that called the Initialize Method and that is where the wrong was.

After some days, I come back to the main project, implement the wMain window, add some more stuff and add the code to initialize the array.
Delete some useless (skeleton/debug) Code / Objects (I wrote to check) and then run.

Surprise, I fully implemented the code and of course it worked.

Sad to be an oldster, most of the time. Next time, I will take my time until the solution comes to me… by itself… magically :wink: .