Bug in Event Structure Hangs GUI

[User002]

Hi all, I think I have found an eventual syntactic and runtime bug in the event structure of LV2012.

Try running the attached code and clicking the boolean buttons as instructed.

FP still responsive? 🙂

A "Try/Catch" that ignores exceptions somewhere in the LV C++ perhaps? 🙂

Br,

/Roger

[RavensFan]

First question.

Why do you think there should be a broken arrow?  Remember, during editing the environment is not goint to predict what the result of the calculations and comparisons would be.  Of course having a selection situation like you have for the event wire doesn't really make sense from an architecture stand point.

Second.

I don't think there is a bug in LabVIEW during run-time.  The problem you are seeing is that you've registered an event, and have failed to handle it in your event structure (the key up on the button.)  If you run your VI and and press the Before button, but drag your mouse off instead of letting the mouse button up, you'll see the front panel doesn't seem to lock up.  Of course one issue you have is that you've registered for a key up event which doesn't make sense for a boolean button.  A mouse up event would make more sense.

[User002]

---

@OriolesFan wrote:

First question.

Why do you think there should be a broken arrow?  Remember, during editing the environment is not goint to predict what the result of the calculations and comparisons would be.  Of course having a selection situation like you have for the event wire doesn't really make sense from an architecture stand point.

Second.

I don't think there is a bug in LabVIEW during run-time.  The problem you are seeing is that you've registered an event, and have failed to handle it in your event structure (the key up on the button.)  If you run your VI and and press the Before button, but drag your mouse off instead of letting the mouse button up, you'll see the front panel doesn't seem to lock up.  Of course one issue you have is that you've registered for a key up event which doesn't make sense for a boolean button.  A mouse up event would make more sense.

---

Because:

Whatever you consider "incorrect" from an 'architecture standpoint' shouldn't hang the FP.

That is simply a bogus statement.

Br,

/Roger

[RavensFan]

Now that variation of the code makes what you posted earlier more interesting.  Perhaps the select statement should have caused a broken wire. There must be something different going on differently with the compiler.  You would think the select statement would behave the same as the case structure from a run-time point of view.  But there are a couple possible things going on that make them different.

1.  At run-time, both paths of the select statement are evaluated.  The condition determines which result gets passed on.  Basically, execution first, decision later.  With a case structure, only the code in the case that meets the condition is executed.  So basically, decision first, execution later.

2.  Newer versions of LabVIEW handled constants wired to case structures differently than older versions.  When the compiler detects the constant and determines that one case can never executed, it doesn't bother compiling the code in that case.  So the data associated with that case (the event type) does not get wrapped up in the refnum wire.  I don't think that same rule applies with a Select statement.  Both paths of execution are compiled (and thus the event types from both are detected.)

---

@User002 wrote:

Whatever you consider "correct" from an 'architecture standpoint' shouldn't hang the FP.

That is simply a bogus statement.

---

No.  It is not a "bogus" statement.  Bad architecture causes all kinds of problems and hangs of the front panel that people who created the bad architecture never expected.  All you have to do is read the posts in the forums and you'll see dozens of these situations everyday.

[User002]

---

@OriolesFan wrote:

1 .Now that variation of the code makes what you posted earlier more interesting.  Perhaps the select statement should have caused a broken wire. There must be something different going on differently with the compiler.  You would think the select statement would behave the same as the case structure from a run-time point of view.  But there are a couple possible things going on that make them different.

1.  At run-time, both paths of the select statement are evaluated.  The condition determines which result gets passed on.  Basically, execution first, decision later.  With a case structure, only the code in the case that meets the condition is executed.  So basically, decision first, execution later.

2.  Newer versions of LabVIEW handled constants wired to case structures differently than older versions.  When the compiler detects the constant and determines that one case can never executed, it doesn't bother compiling the code in that case.  So the data associated with that case (the event type) does not get wrapped up in the refnum wire.  I don't think that same rule applies with a Select statement.  Both paths of execution are compiled (and thus the event types from both are detected.)

---

@User002 wrote:

Whatever you consider "correct" from an 'architecture standpoint' shouldn't hang the FP.

That is simply a bogus statement.

---

No.  It is not a "bogus" statement.  2. Bad architecture causes all kinds of problems and hangs of the front panel that people who created the bad architecture never expected.  All you have to do is read the posts in the forums and you'll see dozens of these situations everyday.

---

1. Indeed it does. 

2. The FP hang is due to some internal error condition that is not handled nor detected by the LV runtime.

My personal opinion is that it should throw an exception that gets taken care of by the LV crash handler.

Br,

/Roger

[RavensFan]

Go to your original VI and eliminate the select statment and the "key up" event.  Just let it dynamically define the Value change.  Your code executes the same way where the FP hangs.

I think that is what really needs to be investigated.

(Note, I've been doing all this in LV2012, I haven't tried in earlier versions.)

EDIT:  I realize what is causing the problem with this later iteration of the code.  You are constantly defining the dynamic event in the loop.  Define the event outside of the loop.

Another thing as for the Select statement.  It seems the definition of the output wire is based on the wire going into the lower False input terminal.  Turn on Context Help and hover over the various wires.  Then change around the two events and do the same.

So I see these issues with your code.

1.  Defining the event over and over in the loop is one way to cause a front panel lockup.  Even if there is no nonsense  select statements, case structures, or other code complicating the definition or execution of the event structure.

2.  Using the select statement causes the event structure to be defined with the False input.  (Valid/Invalid, expected/unexpected, documented/undocumented?  I don't know.)  Then forcing it to alway execute the True wire by way of the constant means you've generated an event that can't be handled.  You may think this is valid architecture that LabVIEW should detect and warn you about, or handle during run-time.  And maybe it should.  But I still say it is bad architecture with an even more advanced LabVIEW tool of dynamic events.  And it isn't really all that different from the bad architecture people write where there are events that are never handled because the structure is placed in code that can never be executed with the front panel set to lock until the event is handled.  (which I still think is a poor default setting.)

[User002]

---

@OriolesFan wrote:

Go to your original VI and eliminate the select statment and the "key up" event.  Just let it dynamically define the Value change.  Your code executes the same way where the FP hangs.

I think that is what really needs to be investigated.

(Note, I've been doing all this in LV2012, I haven't tried in earlier versions.)

EDIT:  I realize what is causing the problem with this later iteration of the code.  You are constantly defining the dynamic event in the loop.  Define the event outside of the loop.

Another thing as for the Select statement.  It seems the definition of the output wire is based on the wire going into the lower False input terminal.  Turn on Context Help and hover over the various wires.  Then change around the two events and do the same.

So I see these issues with your code.

1.  Defining the event over and over in the loop is one way to cause a front panel lockup.  Even if there is no nonsense  select statements, case structures, or other code complicating the definition or execution of the event structure.

2.  Using the select statement causes the event structure to be defined with the False input.  (Valid/Invalid, expected/unexpected, documented/undocumented?  I don't know.)  Then forcing it to alway execute the True wire by way of the constant means you've generated an event that can't be handled.  You may think this is valid architecture that LabVIEW should detect and warn you about, or handle during run-time.  And maybe it should.  But I still say it is bad architecture with an even more advanced LabVIEW tool of dynamic events.  And it isn't really all that different from the bad architecture people write where there are events that are never handled because the structure is placed in code that can never be executed with the front panel set to lock until the event is handled.  (which I still think is a poor default setting.)

---

The code is merely an example of typical ignorant LV runtime behaviour that occurs when there should have been a broken arrow in the first place.

With a stricter LV compiler and verbose exception handling for the coder, maybe you will have to deal with less crappy code on the forums? 

Btw, I have been coding LV for about 10 years. 🙂

Br,

/Roger

[User002 · Accepted solution]

CAR #375765 created by Ninja AE Johan Hillergren. 

Br,

/Roger