Proper event handling in a system

This will be another short post in regards to previously mentioned system about how a system should be structured for proper event handling...

I ran into next big issue, where multiple parts of the system listens to the same update events but where we need one system to be updated first and then the next one.

I really can't find a GOOD way to solve this issue from code. I can find multiple ways to solve it, but none really seems good enough. The usual and easiest way I guess would be that there will be "system wide commands" that is handled by a controller or similar and that that functions in turn calls public functions on other objects or triggers new commands that the model/view listens to.

However, I don't really like that system due to either a lot of public functions or all the issues with trying to debug a flow.

I have really come to like the idea of having a "visual schematic/flow view" where you traverse nodes and then put all synchronization and commands in that place instead of in code. Makes it easier to understand flows and easier to understand where one flow should stop and the next should start etc...

Might have to redo some things on my hobby projet... :o

Issue with my event solution...

This will be a short update mostly as a note to self on why it is bad to use events or something with a strong connection between classes in a solution with garbage collections.

Basically, I have some home brewn event system based around

• Singleton Controller
• Event/Command with id[string]
• Registering interest on controller with ( id[string], cb[Function/Delegate])

And then I would add connection between classes similar to this:

            Controller.instance.registerInterest("id_1", onSpawnParticles);

            Controller.instance.registerInterest("id_2", onReloadDatabase);

Now, due to the issue of the callback being a function, whenever I want to delete something that registered their interest at Controller I would have to manually remove all connections or else GC will always find connections to that class...

I probably should have done this solution with the help of Observer-pattern so I only get one callback and thus only have to do one "unregister" call for each class that falls out of scope... Much easier :o)

Ah well, good thing to learn the hard way :)