Nugget of the week: Dynamic event registration

[Ben]

Hi Jim,

As I understand Ton's example the re-registration of an event to a contant cancels the previous registration, effectivle shutting it off.

Ben

[lmtis]

Hi Ben,
that was my understanding of the gist of his posting, and that is what I am trying to do.  What I don't understand from his picture are the two events on a constant (see attached).  I also don't understand why mine is not working.

[Ben]

The text shown in the header of the evnt structure comes from the code that executes out to the left. In that case, (I think) Ton was creating those events and registering them against the constant so that they would not be registered initially but only registered against the actual picture control when required.

Sorry can't look at your other pictures now, gotta run!

Ben

[TCPlomp]

Hi,

since you can't create event structures and event handlers during execution I use this technique (which is used by NI in their examples as well).
You always need the event handler in the dynamic event parts (with the '<'). To unregister you need to feed a constant, you basically register for a control that does not exist.
If you feed nothing the event will not be unregistered (just like an empty input to an unnamed cluster bundler).
In your code you do the handling in static events, these be unregistered, you could do this by external coding, but it's much nicer to handle it with dynamic events.

Ton

[TCPlomp]

---

If I build multiple references into an array, and wire that array into the dynamic event structure, how can I assign a name to the array such that the event structure can "see" it, and not have the default <?> event name.
...
Any ideas?

---

MikeS shows here a way to rename a wire:

 

Ton

[Neil.Pate]

I like the idea in principle, but is it not a bit risky to rely on Controls[] to always have the same order during development. What I mean is, if you are typecasting each ref to another ref but this time with a label, then the is the possibility of the two arrays getting out of sync with each other?

[TCPlomp]

No, you don't edit the values of the references, just the name of the data (wire).

This is a safe way to do so, just make sure the datatypes of the typecasted wire and the constant are the same! (can be achieved by right-click, create constant). Show the label of the constant and rename the label.

Ton

[Neil.Pate]

I have to say I am not really following you.

In the attached picture: what if the references that are in array A change their order (for whatever reason). You would have to manually change your labels in the array constant B, and you would not even know that the refs in array A had changed their position within the array.

 

.Is this a method for setting the name (for even purposes) of several controls at once, or is this example only showing naming 1 control? If I try and edit the labels of an array constant if I change 1 they all change to the same thing.

 (I think I am not really getting you, can you attach that VI?)

Message Edited by nrp on 08-27-2008 01:58 PM

[F._Schubert]

Hi nrp,

as far as I understand, the label is for the whole array but not the Control lable. As you experience, all elments inside the array have the same lable.

To know which one of the 4 buttons actually was pressed, the Label.Text Property of the control still can be used as normal.

All that is done and makes the code readable is the event name is defined that way.

Felix 

[Intaris]

I first want to say thanks TonP for this nugget!

I've finally grasped User Events and am now in the process of hugely over-using them until I realise they're not an egg-laying, woolly milk-producing pig!  That's a literal translation from German where it makes more sense as "eierlegende Wollmilchsau".  In other words, the solution to all problems rolled into one.

I personally like being able to change the text on the Event (or Event array) independently to the name(s) of the actual Control(s).  Allows functional descriptions which come in very handy using registered events!

Shane.