LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 
Reply

Problems after editing a subVI containing a cluster of dynamic user events

Solved!
Go to solution
Highlighted

 

Hi,

 

I like dynamic events in GUIs as a way of reusing code. But this can lead to registering a lot of dynamic events. To handle this, I often make a subVI that registers them for me. A typical one looks something like this:

register events.PNG

 

Then I utilize it something like so...

event loop.PNG

 

The first time I do it, this works really splendidly and keeps my code (relatively) trim. The problem I've run into on a couple occasions is editing the subVI. Suppose I add a new event. Now my "Event Registration refnum" and "User Events" cluster outputs are broken. No problem: delete those, create new ones, link them to the output terminals. Fine. Now go into the caller. Maybe I've again got to clear out some junk and re-wire here and there due to the type defs. Cool, done. As far as the block diagram goes, everything will look OK at this point; there are no broken wires. However, there are still pesky errors saying "Generate User Event: Contains unwired or bad terminal". 

 

This is obviously some kind of hidden type def conflict. I will typically go through the whole block diagram ripping out wires, nodes, Generate User Event VIs, event loops, cluster unbundlers, the works. Then I code it all back in by hand. Still that gray arrow. I'll mass compile it once or twice. Still a no-go. Make a new VI and copy the code in there. Same problem.

 

I've encountered this problem multiple times and don't think I ever hit upon the solution. Eventually I just revert back to before the changes and give up.

 

Any idea what's going on? How do I break out of this?

 

Thanks,

Nick

"You keep using that word. I do not think it means what you think it means." - Inigo Montoya
0 Kudos
Message 1 of 9
(1,350 Views)

Could you just create the sample vi and post so that it is easy to debug and check where it might be going wrong?

 

Edit: I just remembered once similar thing happened just check the unbundling before the Generate User event which would have become blank, so manually select it and it should be gone.

 

Reedit: I recreated and noticed :Where is event data connected to Generate user event?

Thanks
uday
0 Kudos
Message 2 of 9
(1,334 Views)

No idea how to solve your particular problem, but I can suggest the following. Use a User Event that is a cluster containing a Variant and Command. Rather than having multiple separate User Events, you have one User Event whose command you then parse.

 

Cheers,

mcduff

 

Snap.png

Message 3 of 9
(1,312 Views)
Solution
Accepted by topic author Nickster
09-08-2016 11:11 PM
The error is because the event data terminal is left unconnected at Generate user event which is Terminal of type Required : https://zone.ni.com/reference/en-XX/help/371361H-01/glang/generate_user_event/
Thanks
uday
Message 4 of 9
(1,308 Views)

I can't repeat your trouble, so we need your code or snippet.
Also try make typedef for events cluster and event reg refnum and use it everywhere in your program, this way you'll change your code faster.

0 Kudos
Message 5 of 9
(1,294 Views)

As an aside, did you know that the Merge Errors Function is expandable just like the Build Array Function?

 

Edit: Earlier versions of the Merge Error Function were NOT this way, so I just thought I'd let you know.

Bill
CLD
(Mid-Level minion.)
My support system ensures that I don't look totally incompetent.
Proud to say that I've progressed beyond knowing just enough to be dangerous. I now know enough to know that I have no clue about anything at all.
Humble author of the CLAD Nugget.
0 Kudos
Message 6 of 9
(1,287 Views)

Instead of having a Cluster of User Event Queues, all of type Boolean, why not create an Enum having values Start Job, New Scan, Edit Scan, ... , View Recent, with a single Event Queue called User State..  When you push a Boolean "StartJob", in the Event Loop, generate the User State Event with argument "Start Job".  Now, when you dequeue the Event, you can wire the User State to a Case selector.  One Queue, with the variable being "What I want to do", rather than a Cluster of Queues (much harder to manage).

 

Now you just need to update a single Enum.  When you do this, you also change the Event Registration RefNum, so you need to disconnect and then reconnect it to the Dynamic Event terminal, but that (usually) updates the Event Loop.  [If not, then a Disconnect/Close LabVIEW/Re-open LabVIEW/Reconnect is almost certain to fix this].  Much simpler.

 

Bob Schor

Message 7 of 9
(1,274 Views)

Thanks, uday. Nice eye. Indeed, I do have to go through and patch up old connections due to the new type defs, and in the process I must have wiped out the event data. This was overlooked, because the event data is not at all important to how the events are being used.

 

Then there is the more philosophical question of why that terminal is required at all. ??? Oh well.

 

@Bob_Schor, @mcduff: Thanks for the nice alternatives. I will use those in the future.

"You keep using that word. I do not think it means what you think it means." - Inigo Montoya
0 Kudos
Message 8 of 9
(1,255 Views)

Nickster, sorry, but you seriously?
You don't know how find all mistakes?
If Run arrow broken, press it, and you'll get new window with all errors in VI.
Double click on any error, and system will show you the place with error. And in the error description you can read description of error: required contacts etc.

0 Kudos
Message 9 of 9
(1,231 Views)