unbundle registered events

[Intaris]

I've just started playing about with user events (Me Like!).....

I have a couple of questions to anyone who might be bothered to answer....

Why can't I do somethinglike this?  If I pass a "Register for Events" wire to a sub-VI, I would like under certain circumstances to be able to access the individual events.  I don't seem to be able to do this.  Is there a specific reason for this?  A second method would be to register the events within the sub-vi, but this involves passing either a cluster or array of events....



Shane.


Message Edited by Intaris on 06-02-2008 08:52 AM

Message Edited by Intaris on 06-02-2008 08:52 AM

[andre.buurman@carya]

Never thought about doing it like that. Seems logic from a beginners point of view. Don't see why they couldn't make it like that, maybe add access to the event structure event queue.

I usually store the event refnum in a action machine. With 4 actions "create", "read", "write" and "destroy". This allows access to the event refnum in a clean manner all the way through your application.

[Norbert_B]

Shane,

events are no clusters, even if the wire looks quite similar. If you want to have different types of events, you have to register them all and then you can create an event case for each.



If you only need the data of the event (which is perharps different for the events) you can also create an event with an "generic" dataset (e.g. enum as typedescriptor and a variant as data) and then use this event only....

hope this helps,
Norbert


Message Edited by Norbert B on 06-02-2008 09:00 AM

[Intaris]

I've never used user events or dynamic event registration before in LabVIEW, but I have in Delphi and C#.

In C# and Delphi, registering for an event and firing an event are seperate actions, so I'm assuming that the action I was trying to implement is not possible.

Still, I think it would be cool to be able to do this.  I'm working on the possibility of introducing user events to allow software to control a spectrometer driver.  It could drastically simplify the usage of such a driver in a producer-consumer architecture.  No more middle-man, direct calling of a user event within the driver.....

I suppose I'll have to use a cluster of individual events to achieve what I want.

If anyone can think of any tricks in this direction, I'm all ears.

Shane.

[Intaris]

@ Norbert,

I'm actually looking at a way to FIRE an event represented by the wire carrying the registered events, the listening part is clear.  I don't think this is going to work, so I'll approach it a different way.  I think I need to pass the events individually.

Cheers

Shane.

[Norbert_B]

To add some notes to my previous post:
- Don't mix up the "catching" of an event and the generation of it. You can catch the events in eventstructures... but DO NOT STACK THOSE. So never implement an eventstructure within another function where already an eventstructure is present!
- Generation of events always needs the event, not the registration. So you want to pass the "user event out" wire from the "Create User Event" function. If you have different sets of events, do as i suggested as the second part of my previous posting (Generic datacontainer and something like an ID to know what to do with the data)
- Try not to distribute events and their execution all over you application. You will easily fall into a caveat of the event structure and most propably, the user will be surprised on some.... dependencies which are presumable not intended.....

hope this helps,
Norbert

[Intaris]

@Norbert

Isn't the whole point of the register for events and user events the ability to somewhat decentralise the handling of events?

I'm currently playing with an idea, but I don't see the problems which may arise.  The idea of firing an event within an event structure was just a test case to find out what's possible and what not.

After finding out my idea doesn't work, I also accept that the event registration and event itself are seperate entities.  Just like other languages too.

Aside from the usual caveats regarding Event structures (I'm assuming those who may use the software know what they're doing), what are the possible downsides of an (user)event-based communication with a driver software?  It takes a whole layer of code out of the implementation into an event-driven producer-consumer design.

Shane.


Message Edited by Intaris on 06-02-2008 09:22 AM

Message Edited by Intaris on 06-02-2008 09:23 AM

[Intaris]

Me again,

acute case of verbal finger-tip over-excitement at the moment......

I think the seperation between events and registered events may actually be just what I'm looking for.  The driver could provide a "register for Events" wire for listening for events, and a cluster of events for controlling the driver.  In this way, we can pretty much prevent the user firing an event meant for communication FROM the driver to the user.....

I have to think about this a bit more, but I think it may be quite useful....

Shane

[Norbert_B]

---

@Intaris wrote:
@Norbert

Isn't the whole point of the register for events and user events the ability to somewhat decentralise the handling of events?

[...]

---

Thats true in respect of catching events.
Ok here now what LV does:
When creating an user event, LV creates a dataconstruct which can be registered for. If you register this construct, you will be able to catch those constructs using event structures.
But still, you have to use the handle to the construct to generate an actual event....
This is why many developer work with a generic event structure (see image). Then you have to pass only one reference to user events through the application.



hope this helps,
Norbert

Message Edited by Norbert B on 06-02-2008 09:30 AM

[Intaris]

The universal event data type kind of reminds me of a nugget I posted a while back about a method to have a try at "function overloading in producer consumer designs".

The big disadvantage of this is that it relies on run-time debugging to catch any problems in datatypes due to the variant interpretation.

I'm basically thinking of revealing a set of strictly typed (no variant) events which the user can use to initiate certain actions within the driver.  Feedback is then provided through an event made available via a group of events defined in a single "Register for Events" wire.  This is a fully asynchronous communication mode.

I need to hack together an example to be able to fully understand it's limitations myself.

Ciao

Shane.