A couple weeks ago, I decided to track the opening events of a REALbasic application. I thought I was satisfied with what I had found, because I had answered my main questions. But, I soon realized I had more, particularly as they pertain to the Activate event and controls. One thing leads to another, and all that.

To quickly review, I made a custom object to help track what happens and I stuffed it into a module:

Class OpenSequenceTrackerObj

	Sub Add(theText as string)
		Sequence.Append(theText)
	End Sub
	
	Sub Constructor()
		const kEventName = "OpenSequenceTrackerObj.Constructor"
		me.Add(kEventName)
	End Sub
	
	Private Sequence(-1) As String

End Class

Module Module1

	private mOpenSequenceTracker As OpenSequenceTrackerObj
	OpenSequenceTracker As OpenSequenceTrackerObj
		Get
			if mOpensequencetracker = nil then
				mOpensequencetracker = new OpenSequenceTrackerObj
			end if
			return mOpensequencetracker
		End Get
		
		Set
			// we do nothing here
		End Set
	
End Module

The code contained in the tracked events is simply this:

const kEventName = "Class.Event"
Module1.OpenSequenceTracker.Add(kEventName)

Anyone can write this stuff!

I started off again with the default objects, the App class and the Window class adding the code to the Activate events:

• OpenSequenceTrackObject.Constructor
• App.Open
• Window1.Open
• Window1.Activate
• App.Activate

I find two things that are interesting: The Window events are sandwiched between the App events and the Activate events are fired after the Open events. I suppose the latter makes sense, but it's still on of those "Huh" moments for me.

That's about as interesting as the Activate events can get. But, it got me to thinking about what else is that I do in my apps. Other than EditFields and PushButtons, the two other things I do often is make custom, subclassed Canvas and ListBox objects. As far as I'm concerned, subclassed Canvas objects are the coolest of the cool for controls. So, I threw some code into the Paint event and let it fly...

• OpenSequenceTrackObject.Constructor
• App.Open
• MyCanvasObj.Open
• Window1.Open
• MyCanvasObj.Paint
• Window1.Activate
• App.Activate

I wasn't expecting that. The Canvas.Open event is fired before the Window's Open event. After the Window.Open event, then the Paint event is fired. Honestly, I was working under the notion that all of the controls in a window had their events fire after the window was done, not before. Oops.

I added a subclassd ListBox and looked at what happens...

• OpenSequenceTrackObject.Constructor
• App.Open
• MyCanvasObj.Open
• MyListBoxObj.Open
• Window1.Open
• MyCanvasObj.Paint
• Window1.Activate
• App.Activate

Okay, so nothing nearly as interesting as the Canvas.Paint event, but it's got to be tough for the other controls to compete against that much coolness. But, note all of the Open events and Activate events are grouped together. For kicks and grins, I switched the order in which the custom objects were placed. Before, it was Canvas/ListBox, now it's ListBox/Canvas.

• OpenSequenceTrackObject.Constructor
• App.Open
• MyListBoxObj.Open
• MyCanvasObj.Open
• Window1.Open
• MyCanvasObj.Paint
• Window1.Activate
• App.Activate

The MyListBoxObj.Open is now *before* MyCanvasObj.Open. Relying on that for an application sounds about as reliable as...okay, it wouldn't be.

I think I've about had enough. The significant possibilities have really been exhausted on this one. I could probably go further with adding more Canvases, ListBoxes, and other controls, but I think this is a foregone conclusion. The folks in the REALbasic NUGs and forums who say we cannot rely on the order of events when an application opens are correct. At least now I know why.

Happy coding!