Shift Register Not Re-Initializing

[patrick.wright]

Hello,

I have a sub-vi/dialog which takes an array of objects in, allows the user to manipulate the array, and outputs the changes if OK is pressed, otherwise it outputs the original array.  The input array control to the sub-VI is used to initialize a shift register in the event handler while loop which then passes the changes between events.

My problem is that this works perfectly fine the first time I call the VI.  However, if I exit the VI and then open it again, the shift register is never re-initialized.  I can watch the values progress via probes and I get the new array from the control when the VI is called but the value from the shift register is whatever it was the last time the VI was run.

This code was working to my knowledge before I made a simple change to the control and indicator on the sub VI: instead of being an array of my objects, I changed them to a typedef which is an array of my objects.  Could it be that changing the type (even though it is still the same just encapsulated within a typedef) has caused an issue in LabVIEW?

The array coming from the shift register is empty (probe 14) because I previously (the last time I called the VI) clicked the cancel button which assigns an empty array to the shift register.  However the shift register should not still be empty because I just reinitialized it with the new array (probe 9).

Thanks in advance for any help!

[deceased]

I can't be certain from the picture but it looks like a tunnel on the right of the event structure, before the shift register has a case where it "uses default if unwired".

My guess is that you hit one of them events and that sticks the empty object array in the shift register.

0xDEAD

[crossrulz]

My initial thought is that you actually have a tunnel going underneath the shift register that your wire is connected to instead of the shift register.  Try deleting that wire branch and reconnect to the shift register.

---

@patrick.wright wrote: instead of being an array of my objects, I changed them to a typedef which is an array of my objects.

---

In my opinion, arrays should not be typedefs.  Arrays are containers of a specific type.  In your case, your class is the the typedef.

[patrick.wright]

Yes, in my panel close and cancel events I left the terminal unwired because I didn't really care what value ended up in the shift register and I have the use default option selected.  Perhaps my understanding is wrong, but in both of these events my loop ends and the VI exits so shouldn't the shift register become re-intialized again once the VI restarts thus clearing out the empty array?

[patrick.wright · Accepted solution]

I just figured out what is happening.  Once I click the cancel button, an event is generated which causes the shift register to get the empty array and the loop to exit.  I don't care about this as this is what is supposed to happen.  However, the button unpress (false) event still remains in the queue until I reopen the VI at which point it is immediately processed.  Since the button is unpressed, the loop does not exit, however the shift register is cleared for the next iteration.

Solution: I just made sure to wire up the shift register across the event so that cannot happen.

[RavensFan]

What is the mechanical action of your Cancel button?  It should be Latched when Released.  But it sounds like you might have Switched Until Released which would cause an event on both the Switch Press and the Switch Release.

[Ben]

---

@patrick.wright wrote:

...

Solution: I just made sure to wire up the shift register across the event so that cannot happen.

---

Spoiler

The first time I encountered the complications that come from an event structure that uses "use default if not wired" (back in LV 7.1) it took me quite a while to figure out what was the problem.

I had delivered operational code and then another developer add a new event and failed to wire the across. The new event was a "once in a blue moon type event" so everything seemed to work fine until that blue moon occurred. This resulted in a default file ref when that happened.

Ever since then the "use default" option in an event structure makes me shudder...

Spoiler

A lot like cutting the end off our thumb with a razor knife will forever make you cringe when watching someone else use a razor knife in an unsafe manner.

Spoiler

Technically it is called an evulsion when you cut off a body part that does not involve a bone.

So I avoid the "use Default" just so I can read the code without being disturbed.

Ben 

[Kyle97330]

---

---

Spoiler

The first time I encountered the complications that come from an event structure that uses "use default if not wired" (back in LV 7.1) it took me quite a while to figure out what was the problem.

I had delivered operational code and then another developer add a new event and failed to wire the across. The new event was a "once in a blue moon type event" so everything seemed to work fine until that blue moon occurred. This resulted in a default file ref when that happened.

Ever since then the "use default" option in an event structure makes me shudder...

So I avoid the "use Default" just so I can read the code without being disturbed.

Ben 

---

I've considered writing a VI analyzer check for any output terminal with "use default if unwired" selected that has all of its frames wired at the time of analysis, just to avoid this.  Haven't got around to it yet...

[billko]

Some people like the fact that the default tunnel for event structures is "Use default values if unwired".  I am NOT one of them.

[RavensFan]

---

@billko wrote:

Some people like the fact that the default tunnel for event structures is "Use default values if unwired".  I am NOT one of them.

---

I definitely agree with that.  And for others who agree, be sure to go to Tst's idea Output tunnels from event structure should default to NOT "Use Default if Unwired"

and add your kudoes.