LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

LV2011 bug for references

It seem there is a bug in the LV2011 regrading the reference of type def. or strict type def. control. I created two controls, the first one is normal control and the second one is type def. control. If I get all references of the controls on front panel and search this array of references for normal control and type def. control, the type def. control reference is not found (Search 1D array returns -1) while normal control reference is found. The same code works as expected in LV2010.

 

error.png

Message 1 of 11
(3,236 Views)

I get the same behaviour and cant explain why! However, if you need a work-around (could be done in many ways), here it is:

references.png


CLA CTAChampionI'm attending the GLA Summit!
Subscribe to the Test Automation user group: UK Test Automation Group
0 Kudos
Message 2 of 11
(3,229 Views)

I already made a workaround for my current application, but I have many applications that use similar code on many places and it would take me a grat amount of time to replace all that code Smiley Frustrated.

Message 3 of 11
(3,220 Views)

Thanks for posting this and linking it to the Bug thread.

 

I thought I saw a similar issue being discusedd but it was in the context of an event structure where there was an attempt to ID which of the controls for which the event was registered by comparing the ref returned by the event structure node and the equality failing.

 

But I reviewed all of last years bugs and could find a link to it.

 

At lest this one is linked.

 

THANK YOU!

 

Ben

Retired Senior Automation Systems Architect with Data Science Automation LabVIEW Champion Knight of NI and Prepper LinkedIn Profile YouTube Channel
0 Kudos
Message 4 of 11
(3,190 Views)

@Ben wrote:

But I reviewed all of last years bugs and could find a link to it.


You might be thinking of a 7.x bug which was fixed in 8.0, so it would have been a few years back (and yes, I also remember that thread but I don't feel like digging it up).


___________________
Try to take over the world!
0 Kudos
Message 5 of 11
(3,178 Views)

Ben, I also discovered this bug in event structure in the same case as you described.

 

Do you have any suggestions for a workaround (better than the one suggested by aCe)?

 

0 Kudos
Message 6 of 11
(3,164 Views)

If memory serves me, another work-around invloves a scripting node to get the object ID.

 

Ben

Retired Senior Automation Systems Architect with Data Science Automation LabVIEW Champion Knight of NI and Prepper LinkedIn Profile YouTube Channel
0 Kudos
Message 7 of 11
(3,161 Views)

Just a little funny addition: if one creates a reference to a control BEFORE making it (strictly) type def, it can be found in the VI/Panel/All_Controls[] array even AFTER the control has been changed to type def.

This reference can be copied together with its now type def control to other VIs and it still behaves well.

So the reference seemingly carries some class information or so from its birth.

Anyway, this is not safe: as soon as one deletes and re-creates the refererence, it will not be found any longer.

 

Dirk

0 Kudos
Message 8 of 11
(3,102 Views)

Yes.  References to controls contain knowledge about the type of control it is linked to, after all, they are linked.

 


@DirkLV wrote:

Just a little funny addition: if one creates a reference to a control BEFORE making it (strictly) type def, it can be found in the VI/Panel/All_Controls[] array even AFTER the control has been changed to type def.

This reference can be copied together with its now type def control to other VIs and it still behaves well.

So the reference seemingly carries some class information or so from its birth.

Anyway, this is not safe: as soon as one deletes and re-creates the refererence, it will not be found any longer.

 

Dirk


I don't understand your last sentence.  What are you considering not safe?  What are you "not finding any longer"?

0 Kudos
Message 9 of 11
(3,097 Views)

An example: I found the bug in my application only for 1 particular control. Other controls, now also type def, but probably with "old" references generated as described, could be found via their ref as described by andrej at the very start of this topic (and as one expects it should be for all controls). So it took me quite long to figure out why finding this particluar new type def control in the Controls[] array did not work, while for other type defs it did.

One could use the method I described to create a type def control ref that actually can be found in Controls[]. But if I would delete, for instance by mistake, one of the old refs and then create a new one, it would not be found any longer. So, this method (or call it a "trick") is not safe.

 

Actually I think that one should completely switch to a workaround like the one described by .aCe. In my case, the VI is supposed to be a small library function to find some screen coordinates of a control. So I do not know the type of control that I might wire to it one day.

 

Dirk

 

0 Kudos
Message 10 of 11
(3,069 Views)