Defining Events for an XControl

[mje]

I have an XControl that I'd like the owning VI to be able to respond to events fired from that XControl. My current solution uses dynamic events:

1) Define the state control to hold event references for each event.

2) During initialization, but after deserialization, create the events dynamically and save the references in the state information.

3) The XControl defines read only properties that expose the event references.

4) In the facade, fire the events as needed.

5) Destroy the events during uninit.

When a VI needs an event, it obtains the reference from a property node of the XControl, registers for the event, blocks on an event loop, and eventually unregisters for the event. This appears to works fine in my proof of concept test.

Question is though, is there a way to statically define these events? That is, when you work with "normal" controls, you can select static events from a list when defining a new event case, I'd like my events to appear along side the NI static ones (such as Value Change, Mouse Up, etc) when my XControl is selected from a VIs list of controls and bypass the whole dynamic registration bit.

-michael

[LAVA 1.0 Content]

How wonderful it would be if such things could be arranged I am not aware of such a solution. Yours is the most elegant I can think off.

Could you do me a favor?

Save everything, close your project, then close the VI owning the XControl.

I have an XControl locking everything up (LabVIEW 8.2 through 8.6), NI R&D refused the bug because I couldn't isolate it (That is their job, sorry).

Ton

[mje]

QUOTE (Ton @ Nov 12 2008, 05:20 PM)

I have an XControl locking everything up (LabVIEW 8.2 through 8.6), NI R&D refused the bug because I couldn't isolate it (That is their job, sorry).

I've lost track of the weird behaviors I see when editing XControls, they seem rather random, I have no idea what decides to trigger them. I've pretty much adopted the philosophy of edit my XControl, close all VIs, restart LabVIEW, wave a dead chicken over the computer, and hope stuff works. There's some flaky stuff going on with XControls, and I just don't get it. Sometimes XControl objects are kept in memory even after everything has been closed. Even a "Save All" command from the XControl explorer window won't do it. I can close all the VIs I'm editing, all the VIs that use the XControl...hell, I can close everything LV related and be staring at the Getting Started window with no prompts to save these mysteriously changed VIs. Then when I shut down LV by closing the Getting Started window, whammo, I get asked to save a dozen VIs from my XControl that shouldn't be open anymore...but somehow are? I'll be damned if I can reproduce this behavior but I've seen it a few times.

Other strange behavior I noticed while making this proof. Initially I named the event ValueChangedEvent. Fine fine, then I go ahead and change it to something more descriptive. But for the life of me, I can't get the event name to change. Despite all my efforts to track down where I might be still setting the name to "ValueChangedEvent", I can't find it, yet is somehow appears in my code.

Also, here's one for you: why does a double need to be coerced to a double?

I think I just ought to give up for the night, this isn't making any sense. And honest, I'm sober.

Attached is the proof VI that I fiddled around with, no documentation, but there's really not much to it...

The coercion dot can be found in the facade, and the mystery event name can be seen in the test VI.

Download File:post-11742-1226538104.zip

[LAVA 1.0 Content]

QUOTE (MJE @ Nov 13 2008, 02:12 AM)

Also, here's one for you: why does a double need to be coerced to a double?

http://lavag.org/old_files/monthly_11_2008/post-11742-1226538019.png' target="_blank">

I think your data out is a typedef (and all the wires inside the while loop as well, where the 'Value' isn't one.

Ton

[nhollenback]

Your methodology is exactly what we teach in the LV Advanced I course. And I'm not aware of any other solution at the moment (though I am not completely up on anything that may be in 8.6 ). Your solution really is the only way to do it. But, are you also modifying the cluster in the Convert State for Save Ability. Just redefine the cluster with out the ref before you save the VI and then do the reverse on the Init.

I'm teaching LV Adv next week, so I'll try to reproduce your error (Xcontrol remaining in memory) and get back with you. I'll also look at the event name issue on some of my XControls.

But personally I think your best shot is to stick with the dead chicken! :thumbup:

Nancy

[OlivierL]

QUOTE (MJE @ Nov 12 2008, 05:12 PM)

Other strange behavior I noticed while making this proof. Initially I named the event ValueChangedEvent. Fine fine, then I go ahead and change it to something more descriptive. But for the life of me, I can't get the event name to change. Despite all my efforts to track down where I might be still setting the name to "ValueChangedEvent", I can't find it, yet is somehow appears in my code.

Hi MGE,

to answer your question about htis one, the name inside the <> comes from the data type Label you pass to the Create User Event. As you can see on the image below. The funny behavior is that once you've set the name to something, even if you delete the "User event data type", the name stays. you need to rewire something there, change the label to what you want and then delete it again if you don't need to pass data.

http://lavag.org/old_files/monthly_11_2008/post-12461-1226682034.gif' target="_blank">

Hope this helps.

Olivier