EventHandler, install/uninstall in succession or not

Question

Sorry to bother again, but now I have an architectural question regarding Visa event handlers. I like to react to SRQs several times during the life time of my instrument object, everytime in a different manner. Should I install and uninstall an event handler for each time, or keep it installed and handle the events, which I have to handle each time in a different manner, in that one event handler, which would then call the actual event processing routines according to a state machine variable? The first approach is more elegant, but is there a hardware performance issue? I guess, software performance on a Pentium isn't one.

Answer 1

Gunni:
Ah, the elegance vs. functionality tradeoff. Rest assured that either approach can work fine but each has its pros and cons.
I would definitely say the traditional approach would be to install a single handler once for a given session, then handle the events based on what you are doing at the moment.
Rather than using a global variable, 1 way to keep the information more local might be to call "sess.SetAttribute (VI_ATTR_USER_DATA,value);". I'll admit to not remembering the exact syntax but I'm pretty sure that's about right. Then in your callback you can do "sess.GetAttribute(VI_ATTR_USER_DATA,&value);" and know your session's state information. Remember that this can hold any 32-bit value, including a pointer if you cast it appropriately.
On the other hand, if you want to install/uninstall a handler appropriate for the given task, make sure you remember to call EnableEvent after installing your handler (since the previous uninstall will automatically call DisableEvent). Also, make sure you install and enable just before setting up the instrument to generate an SRQ in order to avoid any race conditions. This may make the handler more elegant but potentially clutters your other code.
My recommendation would be to use the first method (always keep it installed). If a big switch statement in the handler is unappealing, try this. Make all your actual event processing routines take the same parameter list, and just set the VI_ATTR_USER_DATA value to the function pointer of the routine. Then the handler can just invoke the function pointer (with the appropriate parameters) instead of doing a switch. This will likely require that the actual event processing routines be non-member functions, and I'm pretty sure they can't be virtual ones, since you can never get a direct pointer for these.
I hope this gives you more insight into your various options. Again, it really doesn't matter too much because any of these ought to work.
Dan Mondrik
Senior Software Engineer, NI-VISA
National Instruments