Leaderboard

It turns out upcasting the child data object to the EventData object didn't work out as well as I had hoped. So I tinkered around with it for a while and came up with a better solution. I ended up with what I think will be a highly reusable EventManagerTemplate code module that meets almost all of my goals. Adding a new event only requires deriving a new MyEvent class and a new MyEventData class with a single Create sub vi for each of them (though you do need to add getter methods to MyEventData if it carries data), and adding one GetMyEventRefnum vi to the EventManager class. No need to create duplicate RaiseEvent or DestroyEvent methods. No need for the event consumer to type check the event data object in the event structure, OR to downcast it to the proper event data subclass. If there's enough demand I'll try to spend some time cleaning it up and documenting it. No promises on how soon I could post it though... it would likely be at least a week. In the meantime, here's a screenshot of a quick example I rigged up. ------------------------------------- I've reconsidered. Rather than throwing an error, how about forcing an upcast to the parent object at the Reg Events prim? The registration wire would still be strongly typed, which as near as I can tell is really the one that matters, and the user event wire could be polymorphic. (Maybe that's what's happening in 2009?) Not on this project unfortunately. What happens when you try to wire a parent class user event and child class user event to the same output node in a case block? Ah, I think I understand. If the command subclass knows what vi has the additional information it needs to execute it's process, it can obtain a reference to that vi at runtime and acquire the data it needs from the fp controls. Am I close?