typedef and strict typedef control vi server reference issue LV 2011

[KuGr]

Here are the steps I did...

1) On my FP I have a strict typedef control.  As an example simple Boolean in the strict typedef control.

2) On my BD I make a VI Server Reference to the strict type def control created in #1.

3) I have an event structure that handles the event when the strict typedef has a value change.

4) The Event Structures Data Node has the CtlRef for the strict typedef control added in #1.

So here is the scenario:  The VI is running.  I change the value of the strict type def control.  The event structure captures the value change event.  I then compare the refnum value from #2 with the CtlRef from #4.  The refnums are not the same.  This was not the case in LV2009 and LV2010.

As a side note, I can use either the VI Server Reference from #2 or the CtlRef from #4 to change the value with a value property node.  It will update the FP control.  So internally they reference the same FP.  But the reference values are not.

This only happens with typedef and strict typedef controls, not 'plain' controls.  I have not tried it with multiple controls in a typedef.

As this is not the case in 2009 or 2010, is this the new expected behavior?

[smercurio_fc]

The actual values of the references don't need to be the same. The references would be "equal" if they point to the same object. In fact, the LabVIEW Help explicitly says "When comparing VI Server references, these functions return TRUE or FALSE based on whether the two references refer to the same object, regardless of whether the references have the same value or the same capability." What's puzzling is why the Equal returns False, when it appears they are actually pointing to the same object. When I replicated what you did I looked at the UID for the manually created reference and the CtlRef data node value, and they were the same. So I don't quite understand why the Equal says false.

[KuGr]

Thank you for looking into this.

So, to make sure I understood you correctly.  You were able to duplicate the case when wired to an 'Equal?' function, it returned false when you expected it to return true?

That is what I am seeing in LV2011.  Essentially I have a collection of control refnums that I compare the Event Data Node's CtlRef against.  I did not get a match even though a match was expected.

[Ben]

That is a bug that will break my code I I had used a typedef!

I use that technique in simle dialogs to determine (in a loopless event) to determine if they hit OK or Cancel.

It works the way I expect in LV 8.6 but I see the same failure in LV 2011.

I think its a bug.

Ben

[smercurio_fc]

---

@KuGr wrote:

Thank you for looking into this.

So, to make sure I understood you correctly.  You were able to duplicate the case when wired to an 'Equal?' function, it returned false when you expected it to return true?

---

Yes. that is what I saw. Based on the documentation I expected a true, but got a false. I did not look at it any further, but I would definitely say that something appears to be wrong here.

[Ben]

I did look further.

If you probe the wires you will different values for the ref in the event structure and the ref node.

Smae code in LV 8.2 shows identicle numbers and returns True.

Disconnecting the type def it works correctly.

The instructors here in the office suspect the new compiler.

Ben

[alcava.cr · Accepted solution]

This issue has been reported to NI R&D as Corrective Action Request (CAR# 323101) for further investigation. Thanks for the feedback!

[KuGr]

Thanks to all for validating and generating a CAR!

[Ben]

Thanks for the CAR.

Like the recently discovered bug about variants taking up more memory under 2011, I would like to hear what R&D has to say about this bug. These bugs may prevent my up-grading to 2011...

"The devil we know is better than the devile we don't know."

Ben

[sbus]

I need to understand a bit more about this issue as it may impact problems I've been seeing under LV2011 with typedefs.

My understanding is that the literal 'value of a reference' is an opaque Labview number that is not relevant to programmer's. The value derived from the value property most certainly is - it is the data that the object the refnum references is set to. If you are comparing the value of the reference itself, I don't understand why, please explain. If you are comparing the value of the underlying object, then I do understand and agree it is a bug.

When you say the 'value of the ref' do you mean that you actually probe the reference itself, or the value property of the object that the refnum references? Can you post a screenshot of an example BD?