Complicated app architecture

BlitzMax Forums/MaxGUI Module/Complicated app architecture

JoshK

(Posted 2007) [#1]

I have been making extensive use of hooks and emitted events in BlitzMax.

For example, every window in my program has an EmitEventHook. This evaluates all events that are relevant to that window or groups of gadgets. I find this approach much easier to break events up this way, because otherwise my event evaluation source file gets way too big. It also makes it very easy to mix and match various GUI elements. For example, I could include a new browser control in my main program with one source file, without having to modify the main source:

Function MainWindowHook:Object(id,data:Object,context:Object)
	Local editorviewport:TEditorViewport
	Local event:TEvent=TEvent(data)
	If Not event Return data
	Select event.id
		Case EVENT_WINDOWCLOSE
			Select event.source
				Case MainWindow
					EmitEvent CreateEvent(EVENT_MENUACTION,Null,MENU_EXIT)
					Return Null
			EndSelect
		Case EVENT_MENUACTION
			Select event.data
				Case MENU_EXIT
					HideGadget MainWindow
					StopEngine()
					End
					Return Null
			EndSelect
	EndSelect
	Return data
EndFunction

The other interesting thing I have been doing is replacing redundant event evalaluation with an EmitEvent() call. For example in the above code, both the menu action and the window close will end the program. When the window is closed, I just emit a menu event that makes the program think the Exit menu was pressed. This makes it so I only have to write the code to process that event once.

My main program loop then looks like this:

Repeat
WaitEvent()
Forever

Everything is handled in callbacks! This approach is very different than what I am used to, but it seems to work well, and it compartmentalizes the code very easily.

Are there any potential problems with this approach?

Mark Tiffany

(Posted 2007) [#2]

I find debugging can be a little bit harder when doing this (but not much) - it's a little bit harder to trace through the code in a procedural manner to identify the problem. But equally, because you can bew sure (well, as sure as you can be in your own code) that common code is used wherever possible, once you find the problem, it's often easier to fix.

One problem that may occur in the future would arise with threading. If 'max were multi-threaded, you might find that the emitted event code is executed before the code that is emitting the event finishes. It depends on how the threading / event handler works, and should be avoidable (or manageable), and is pretty much a moot point given 'max doesn't have threads.

FlameDuck

(Posted 2007) [#3]

Are there any potential problems with this approach?

Apart from callbacks not being typesafe (aka. delegates), no there's nothing wrong with that. In fact it's generally the "preferred" method of doing things in any event-driven SPOT language.