Getting data from a callback vi

[SteveMoores]

I have registered an event and have a callback vi which is called on an occurrence of the event.
My main vi in which the callback vi is registered requires to know when the callback vi has completed its task. It appears obvious to set a global variable which both the main vi and the callback vi cain gain access to, the callback vi can then set the global flag and the main vi can then continue. This does not appear to be a 'nice' way of doing things, I am fairly new to LabView and wondered if there was a better way of doing this ? Can i not return data from the callback vi ? can I not detect that the callback vi has terminated ? ( if in fact it does terminate upon completion )

[srm@viewpointusa.com]

your method will work and would be acceptable code practice for the way you describe. Is your main loop polling or do you want it to "go to sleep" and wake up on the callback? Yes, it may not be "nice". You can also look to the semiphore, notifier, and occurances. If you want to pass data, you may look to queues

[Greg_McKaskle2]

> I have registered an event and have a callback vi which is called on
> an occurrence of the event.
> My main vi in which the callback vi is registered requires to know
> when the callback vi has completed its task. It appears obvious to set
> a global variable which both the main vi and the callback vi cain gain
> access to, the callback vi can then set the global flag and the main
> vi can then continue. This does not appear to be a 'nice' way of doing
> things, I am fairly new to LabView and wondered if there was a better
> way of doing this ? Can i not return data from the callback vi ? can I
> not detect that the callback vi has terminated ? ( if in fact it does
> terminate upon completion )

I'd suggest you not use callback VIs, but use the event
structure to
catch and handle the event. Callbacks are difficult to deal with,
especially in languages that have scoping and do not have generic
pointers. Even then, they require lots of shared data between possibly
parallel pieces of code. And this is why we suggest you look in
examples/general for the UI and dynamic event examples.

The callback mechanism had to be implemented for ActiveX since their
event architecture is really more of a synchronous messaging system
rather than an event system, and they are incompatible with the event
structure when the events provoke other events and need to reenter the
original. If not using ActiveX events, stick with the structure, it is
much simpler to use.

Greg McKaskle