There are many things that happen, or can happen, BEFORE the App.open 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