[CR] LVOOP Event Handler

[Francois Normandin]

Name: LVOOP Event Handler

Submitter: François Normandin

Submitted: 07 Oct 2010

File Updated: 03 Jan 2011

Category: LabVIEW OOP

LabVIEW Version: 2009

License Type: BSD (Most common)

LVOOP Event Handler v1.0.1

Copyright © 2010, François Normandin.

All rights reserved.

Author:François Normandin

Contact Info: Contact via PM on www.lavag.org

LabVIEW Versions:

Created and tested with LabVIEW 2009

Dependencies:

openg_appcontrol 2.10

openg_error 2.3

Description:

This is a package that provides the framework for a LVOOP Subscribable Event Handler.

Processes can dynamically register new events and list the classes that are allowed to subscribe to it.

Once a TopProcess takes ownership of the Handler, it manages a Global Stop event and a Handler Activity event to inform subscribers that a new event has been registered with the handler. All subscribers can then get a list of all the events they are allowed to subscribe to.

Everything is done through events with LVOOP LVObject as a backbone. The subscriber will then be free to implement its interpretation of the subscribe event content when received, by casting to the known object types.

Instructions:

After installing package with VIPM, refresh palettes if VIPM is not set to refresh automatically.

Use palette to find the LVOOP Event Handler. Select the Event Handler VI and drop it in your application.

There is a test program that shows how data is exchanged between three dummy classes. You can open the front panel

of the Event Handler to see what are the actual allowed subscribers for which event owner.

Known Issues:

Acknowledgements:

History:

v1.0.0: Initial release of the code. (2009)

v1.0.1: Fixed a wrong connection with the "Preserve RunTime Class" primitive where children classes were not considered as such when a parent class was passed.

Better error handling on Destroy Handler command. (Caused a code 1 error when event destroyed by owner prior handler command.

Added the Event Description string to the connector pane.

License:

Distributed under the BSD license.

Support:

If you have any problems with this code or want to suggest features:

please go to www.lavag.org and Navigate to the discussion page.

Distribution:

This code was downloaded from the LAVA Code Repository found at www.lavag.org

============================

How it works:

This framework consists of a FGV Event Handler that manages the interactions between publishers and subscribers to events. It consists of some commands that allow the use of generic LVOOP events.

It allows the owner to control a Global Stop command, which can be listened by any VI. Once initialized, any process can register its own events and choose which classes are able to subscribe dynamically to it.

A generic event notifies all subscribers to a change in the list of the events available, so that no VI needs to poll constantly to detect the new events or unsubscribe from events that are unregistered by its owner.

Commands:

1- Initialize Handler: The first VI to call the initialization takes ownership of the handler. All other calls before the handler is destroyed will return an error.

2- Subscribe: Default case. When a VI subscribes to event, it will receive a list of all events for which it is allowed to register. Then the VI can decide what it does with the incoming data on that event channel.

3- Register: Any VI can register an event refnum (LVOOP type) and decide which object types can subscribe to it. If no input is provided, or if LVObject is in the list, then all are allowed to subscribe. A notification is sent via the Handler Activity event.

4- Unregister: Any VI that owns an event can remove it from the list. A notification is sent to everyone that listens to the Handler Activity event to prevent the need for poling.

5- Global Stop: Only the owner of the handler can call a global stop. It is meant to protect the integrity of the program should a subscriber decide to play god.

6- Destroy Handler: Releases the command to any process that wants to initialize it. It also erases all events still registered. It can only be called by the Handler's owner.

***************

There is an example VI in the LVOOP Event Handler palette.

Click here to download this file

[Francois Normandin]

There was a switched connector on the Preserve RunTIme Class primitive that escaped my initial tests. This caused a problem for child classes not recognizing that they were allowed to subscribe to certain events.

This is corrected in 1.0.1. Sorry for this.

[Francois Normandin]

Thanks for sharing this Francois,

After installing it, I have in my palette only two VIs exposed (one of them is the test VI, and the other is the FGV). Is this all that should be there or am I missing something.

Hello Neil,

that's it. Isn't it wonderfully simple? Kidding aside, the FGV is the only VI you will need if you use this piece of code. I plan to add stuff in the palette in the form of "Drop VI Content" to speed up development around this FGV... but essentially, this VI is the core of my way of handling LVOOP events between processes. Eventually, there might be a series of low-level objects that might be distributed with it, but that's the cherry on the sundae and some programmers might not like cherries after all, so we'll see after I show some examples.

I didn't find time in the long weekend to finalize the examples I want to share. For now, it's might not be obvious how I intended people to use it, and I apologize for that. I'll have a demo on how you can "pimp" your state machine template and certainly a small real-world application to remove some fog around it.

[CharlesB]

Hi,

This package looks interesting, however not compatible with LV2010 (wires are broken when wiring the event).

Best,

Charles

Edited March 28, 2011 by CharlesB

[Francois Normandin]

Hi Charles,

I had missed your post.

I'll have a look at this.

thanks for reporting.

[Francois Normandin]

OK, the reason it breaks the code is that I used a technique that could be unsafe if used otherwise. I results from a bug in LV2009, that was not announced (to my knowledge) but that has been corrected in LV2010.

I have good reason to believe that the code is safe in LV2009, if you use the Handler as described. However, I cannot garantee that it will not crash as shown in this thread.

I've posted an example over there, derived from AQ's explanations, as to how it can easily lead to stop LabVIEW (or crash it).