Leaderboard

Man, I hope Todd (the judge) picks my questions to use for the Challenge this year. I submitted a couple really cool (IMHO) ideas. For those who weren't there last year, the challenge I submitted was to write a VI that failed at least 10 of the VI Analyzer style tests. It was quite amusing watching programmers have to fight their own tendencies to write good code -- one person kept reflexively fixing the style problem and had to keep putting it back as he worked. :-) I don't sleep that week. Hanging out with Norm and attempting to leech some of his infinite energy is sometimes useful strategy. I've also attempted simultaneous physical manifestations in multiple locations... that works, but the reintegration is a real pain. Reading blogs later for the sessions you miss works better.

This is what most of my VIs do with the various sync objects (including dynamic event regs). The problem is this: Alpha is going to dynamically launch Beta, and needs some kind of sync object to communicate with Beta. It needs to know that once that object exists, it can be used and Beta will (eventually) receive all signals sent to it. Two solutions present themselves to me. Alpha creates the object and passes ownership of it off to Beta. I dislike this because it violates the destroy what you create practice, but it is the simplest way to solve the problem. Even if it's a dynamic event reg, if Alpha creates it, the reg is capable of receiving events even before Beta is ready to receive them. Alpha creates a temporary sync object to pass to Beta (usually a notifier to hold the final sync object reference), starts up Beta, then blocks on the temporary notifier. Beta starts, creates the permanent object which it owns, and signals Alpha using the temporary object, then continues on its way. Meanwhile, Alpha receives the permanent object reference, takes note of it, and continues on it's way, passing signals as appropriate. The second way is by far the more extensible of the two, but there is that added layer of complexity. Of course the whole situation is made much easier if we just don't care if Beta misses a few signals. In that case the ownership of the sync object can be managed by Alpha.

See here - http://decibel.ni.com/content/groups/ui/blog/2010/04/29/creating-quality-uis-with-ni-labview--developer-days-2010-presentation The touch panel example is the relevant one. My understanding has always been that the module converts the code to C (like the embedded module) and then uses eVC to compile it. I expect that this is the source of most of the bugs, since it's a process which is considerably different than the desktop app-builder. Anyway, you should be happy you have tabs. If memory serves, the first version of the PDA module didn't have them.

I don't think this is a bug at all. You've programmed a race condition. Even with the delay call, your code's behavior is undefined. Signaling the event (or generating/broadcasting it in LV language) obviously won't wait for the event to be processed, but it's important to also realize that it doesn't even wait for the event consumer(s) to be invoked. The event is entirely asynchronous. Broadcasting simply queues the event up for each registered consumer of the event. With no wait, your VI will (usually) just blow through the broadcast, then go ahead an unregister the event, which will destroy the event queue, in the process neutralizing the uninvoked event (along with any other events in the queue). Add in a wait as you show, and your program will sometimes yield to a context switch allowing your consumer code to invoke, but you can't be certain it always will. The code behavior is by its very nature undefined. To avoid this, you can handle event unregistration in the consumer portion of code. Once the consumer receives the event, it unregisters itself and finishes up.