LabVIEW Event names are completely off

[PeterFoerster]

Hello all,

I just encountered my strangest LabVIEW bug yet: I re-installed LabVIEW 2015 SP1 this morning. All the other modules I use were installed and I installed LabVIEW "under" those modules. When I just used it for the first time I noticed some strange behaviour:

When I created an event structure the default event case it was created with was the "selection change". I wondered what had happened to time out and when I tried to change it to value change it was called "Key repeat". Scratching my head a bit further I found out, that the events seem to be renamed only, so key repeat behaves exactly as value change would but it gives me back the event data node that belongs to the key repeat element.

In addition to all, there is also a <this VI>/Event17 which I'm a bit afraid to find out what it does and which will also be the name of the bar I'm going to open if I can't get this solved and have to go into exile.

Is this a known issue?

My Exact Version of LabVIEW is: 15.0.1f10 (32-bit)

I think I'm going to try reinstalling it and see if that helps. I'm open for suggestions both for the solution of this issue and good mental health institutions.

Possible causes:

The re-installation this morning. I accidentally uninstalled it, when trying to repair the CVI Runtime engine. The partial reinstall could have screwed something up.
Or maybe it was the installation of NXG last week. idk

P.S.: O course, I should mention that this is also the case for my existing projects.

[Darren]

I've seen property/method/event names get mixed up before. The only solution I know of is to repair/reinstall LabVIEW.

[Ben]

I saw events get scrambled when using dynamic event registration and adding deleting registrations. the event structure did not keep up with the registered event changes.

That is one reason I advocate registering for in the same VI as the event structure because it is real easy to scramble the events.

Ben

[PeterFoerster]

---

wrote:

I've seen property/method/event names get mixed up before. The only solution I know of is to repair/reinstall LabVIEW.

---

OK, I will try that. BTW: What happened to the repair option? Control Panel >> Software >> National Instruments Software leads me to the NI-Package Manager where I can't find a repair option.

[PeterFoerster]

OK, neither partial nor complete re-installation helped. Still the same issue and the same names. It could have at least shifted them one more...

[Darren]

Weird. If you create a new VI with an event structure, are the events messed up? Like when you first drop a new one, does it show the 'Timeout' event? And if you add a new event for a control, does it show the name correctly?

If new event structures look ok, then I guess something may be corrupted with your VI itself. Could you try opening that VI on another computer with LabVIEW installed and see if the events are still messed up?

If the VI is corrupted, there's not much you can do except go back to a previous version in Source Control. If you're not using Source Control, then you'll have to recreate the event structure from scratch.

[PeterFoerster · Accepted solution]

It has probably gotten a bit confusing: Both new VIs and existing VIs show this behaviour. When I drop a new event structure, on the BD it shows the "selection change" event instead of the expected timeout. It is definitely not a problem of the VIs, since they work everywhere else.

I got the problem fixed, by running msi... you know...

BTW: After complete uninstall with the package manager, there's still 1,2 GB in Programs/National Instruments and 15 GB in ProgramData/National Instruments. That's a bit much, innit? I mean this considering the msi... you know... does not officially exist. A new user would probably not think about deleting those folders after uninstalling.

And did I just miss the repair option in VI Package manager?

[wiebe@CARYA]

---

@Ben wrote:

I saw events get scrambled when using dynamic event registration and adding deleting registrations. the event structure did not keep up with the registered event changes.

---

That's actually 100% reproducible for me. In other words: very annoying.

---

Ben wrote: 

That is one reason I advocate registering for in the same VI as the event structure because it is real easy to scramble the events.

---

But then an object has to expose a user event instead of the event registration. That user event could be abused now it is exposed. Exposing the event registration is safer from an encapsulation point of view... Between a rock and a hard place...

[Ben]

---

wrote:

---

@Ben wrote:

I saw events get scrambled when using dynamic event registration and adding deleting registrations. the event structure did not keep up with the registered event changes.

---

That's actually 100% reproducible for me. In other words: very annoying.

---

Ben wrote: 

That is one reason I advocate registering for in the same VI as the event structure because it is real easy to scramble the events.

---

But then an object has to expose a user event instead of the event registration. That user event could be abused now it is exposed. Exposing the event registration is safer from an encapsulation point of view... Between a rock and a hard place...

---

there is another risk that I guard against and that is rookie mistakes by those that follow me. On more than one occasion I have pointed out to less experienced developers that the event registration wire can NOT be forked. Coming from a sub-VI they have branched the wire to two or more vent structures. The one-to -one relationship is (well almost) implied when the two are in the same diagram.

Hint:

If you really want to hack up the event registration, then take the time to put a note in EVERY event case that can be used as a clue as to "what it was" so that if things do get scrambled... you can put Humpty Dumpty back together again.

I should also point out that dividing the events associated with various modes of operation of the application can really make our lives easier.

Example:

Config Mode

Put all of the code required to support the GUI behavior while in Config mode in a sub-VI and use dynamic event registration to register for the needed events. Keep it focused on just the Config stuff. By doing so we get easier to understand code in that if there is an issue with how things work in Config mode, we know which sub-VI to look at. When we do find the right sub-VI, we only have a limited number of events and not a list of events that trickle down off the screen. When you are dyslexic like me, the last thing you want is to do is use a graphical language to develop what amounts to a text based labrynth where my eyes start crossing.

Sure I realize this goes against the common advise to "just use one event structure" but they also tell us walk before we run etc.

Just my 2 cents,

Ben 

[wiebe@CARYA]

---

wrote:

---

wrote:

---

@Ben wrote:

I saw events get scrambled when using dynamic event registration and adding deleting registrations. the event structure did not keep up with the registered event changes.

---

That's actually 100% reproducible for me. In other words: very annoying.

---

Ben wrote: 

That is one reason I advocate registering for in the same VI as the event structure because it is real easy to scramble the events.

---

But then an object has to expose a user event instead of the event registration. That user event could be abused now it is exposed. Exposing the event registration is safer from an encapsulation point of view... Between a rock and a hard place...

---

there is another risk that I guard against and that is rookie mistakes by those that follow me. On more than one occasion I have pointed out to less experienced developers that the event registration wire can NOT be forked. Coming from a sub-VI they have branched the wire to two or more vent structures. The one-to -one relationship is (well almost) implied when the two are in the same diagram.

---

Another risk is that the Register Event VI can called (maybe it's even done in the init), but never wired to an event structure. That's a memory leak, since all the events get queued up after registration (by design, it should be like that). Registering, and not using it will bring disaster.