Callbacks and Events

[ShaunR]

I was searching for a way of being able to effect events from dynaimically loaded vi's elagantly.

These vi's make it very difficult to use with events and generally it gets all messy with globals since you have to wire them somehow.

Then I stumbled upon callbacks (never seen them before). And there doesn't seem to be much information about them apart from using with Active X, so I thought I'd knock up an example to demonstrate their enormous member power.

The example attaches a couple of callbacks onto a dynamically loaded vi's controls. One callback is an event generator so that any time a value changes on the dynamically loaded vi, our custom event fires in our top level vi. Every time we load a vi, we attach these callbacks, meaning that any vi will generate our event.

[mje]

I also like the idea of callbacks. I've previously used an object based implementation to abstract the callback mechanism such that the choice of implementation (notifiers, events, VIs, or anything else) is transparent to a given framework. I've since moved to using such an abstraction almost exclusively now, I rarely use raw notifiers and what not for simple synchronization or cross task communication as the flexibility of a generic callback is much more elegant.

[ShaunR]

QUOTE (MJE @ May 1 2009, 03:52 PM)

I also like the idea of callbacks. I've http://forums.lavag.org/MessagePump-A-Messaging-Framework-Class-t13291.html#entry60420' target="_blank">previously used an object based implementation to abstract the callback mechanism such that the choice of implementation (notifiers, events, VIs, or anything else) is transparent to a given framework. I've since moved to using such an abstraction almost exclusively now, I rarely use raw notifiers and what not for simple synchronization or cross task communication as the flexibility of a generic callback is much more elegant.

I like the abstraction, and can see a use in some of my applications. I'm ambivalent about OOP in Labview......but that's another thread.

The idea isn't about notifiers or events really (but it does use the native labview events). Its about the hooking of Labviews existing events (the string controls for example don't use custom events, notifiers etc). The Message Pump callback seems a bit different in that respect.

The main difference in your approach seems to be that it is a one to many (the great tentacled controller/supervisor) which doesn't fit most of my implemented models which are many to one. Mine generally use an encapsulated autonomous approach so the "controller" merely has to launch them, provide an interface to the user and then sit around twiddling its thumbs until something interesting happens. Therefore the ability to hook the controls/indicators (even the whole VI or application) is a boon since it requires no code changes in existing VI's (well, maybe have to use the Val(sigl) instead of the direct wiring....but can live with that) and if I add modules they are automagically catered for if/when I call them at run time. It also dramatically reduces wiring and global use without implementing a messaging scheme.

One limitation,however, is the number of events that Labview exposes that you can attach to. For example, the Application Reference only exposes a pitiful 3 events for VI's (Activate, Redraw and Scroll). If we had a "Load" equivalent, for example, we could run an event registration callback when a vi loads and we could hook the "Panel Close" to unregister. Then adding VI's would seamlessly fit into our application event system and enable it to be used as many to many. I would also really like to be able to attach to VISA and have proper events that I can handle with an event structure.

[mje]

Oh yes, I realize the two implementations are quite different, I like how you attached your callbacks. I saw your code for VI and event callbacks, and saw an abstraction there that was similar to what I had done via the Callback and related classes I had used so I thought I'd chime in.

The real power of your way of doing it is you can use the callbacks to register for events generated outside of LabVIEW that are exposed in .NET or ActiveX objects. Basically, using the callback mechanism you used, LV code can synchronize with virtually any modern Windows code.

And for the record, I too am somewhat disappointed at how events haven't evolved with LabVIEW. They are very powerful and I use them all the time, but I also find the exposed interface to often be lacking.

[ShaunR]

QUOTE (MJE @ May 2 2009, 05:50 PM)

The real power of your way of doing it is you can use the callbacks to register for events generated outside of LabVIEW that are exposed in .NET or ActiveX objects. Basically, using the callback mechanism you used, LV code can synchronize with virtually any modern Windows code.

Funny you should say that.

When I found it. It was used for hooking the I.E. browser Active X control (and its on the .Net pallet so presumably that was the intention). I'm not clever enough to come up with these things on my own But I am ruthless enough to exploit them for every ounce of worth However, I have an aversion to active X and the obese .Net (for many reasons but the main one being, if I don't have the source, I can't use it). But I did see a potential for using it within Labview for a scenario that I'd been working around for a while and wasn't satisfied with. And as I explored, a whole new mechanism for inter process comms opened up with (it seems) few drawbacks.

I think what I like about your Message Pump implementation is that it it goes far enough to be more than useful without being so huge and complicated to make it unusable. I see many OOP module designs (not just in Labview) that try to be all things to all people rather than a base from which people can start.Your porridge is "just right".

[TG]

QUOTE (ShaunR @ May 1 2009, 11:49 AM)

I d like to learn more about callbacks and messaging architecture that encapsulates most of the details of messaging, etc.

I have no idea why (yet) but I tried to open or look into both zip files,

The Message pump zip and

and your Callback LLB and could not open either in labVIEW 8.5.1

It looke like the message pump library looking for semaphore support in LabVIEW 6 and the Callback LLB simply will not open beyond the

LLB manager window for some reason

ANyway hope I can figure this out.

Anyone else have success looking at these zips?

Thx

[mje]

The MessagePump is saved in LV 8.6, I doubt it can be opened in previous versions.

[ShaunR]

Yes. The callbacks were also saved in 8.6.1.

I've attempted to save back to 8.0 and took them out of the LLB. Hopefully converted them all, but labview was very insistant on saving them in its current version.

Try these anyway and let me know.

Download File:post-15232-1241736385.zip

[Mark Yedinak]

Yes. The callbacks were also saved in 8.6.1.

I've attempted to save back to 8.0 and took them out of the LLB. Hopefully converted them all, but labview was very insistant on saving them in its current version.

Try these anyway and let me know.

Download File:post-15232-1241736385.zip

Thanks Shun. This is close but it still requires knowledge of the subVI. This requires that the calling application knows the names of the controls of the subVI for processing. Overall this is a reasonable work around but ultimately I am looking for a truly generic solution which decouples the top level VI from the called subVIs.

All I want to know is when the subVI exited. I don't want to know anything about the internals of the spawned VI nor do I want to require the spawned subVI from having to do anything special to inform the caller that it has exited. It would seem reasonable that the caller should be able to be informed of specific events of the spawned VI.

I do appreciate the suggestions though. And this callback solution could be useful for other tasks.

[ShaunR]

Thanks Shun. This is close but it still requires knowledge of the subVI. This requires that the calling application knows the names of the controls of the subVI for processing. Overall this is a reasonable work around but ultimately I am looking for a truly generic solution which decouples the top level VI from the called subVIs.

All I want to know is when the subVI exited. I don't want to know anything about the internals of the spawned VI nor do I want to require the spawned subVI from having to do anything special to inform the caller that it has exited. It would seem reasonable that the caller should be able to be informed of specific events of the spawned VI.

I do appreciate the suggestions though. And this callback solution could be useful for other tasks.

The example does, yes. Because you don't know what controls maybe on the front panel. But ALL vis have a generic on-close event So don't need to know anything about the sub VI. You just inspect the reference when the event comes in to find out which VI closed.

So the install callback just becomes:

Haven't been through it thoroughly and perhaps not as "clean" as you would like (I suspect you were expecting to just select it with 0 programming). But better than nothing eh?

Oppps. Posted on wrong thread...lol.

Edited October 5, 2010 by ShaunR