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

[Nickster]

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:

Then I utilize it something like so...

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

[udka]

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?

[mcduff]

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

[udka · Accepted solution]

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/

[Artem.SPb]

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.

[billko]

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.

[Bob_Schor]

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

[Nickster]

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.

[Artem.SPb]

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.