01-18-2012 03:09 AM
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.
01-18-2012 03:39 AM
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:
01-18-2012 03:58 AM
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 .
01-18-2012 07:53 AM
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
01-18-2012 08:34 AM
@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).
01-18-2012 10:47 AM
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)?
01-18-2012 10:55 AM
If memory serves me, another work-around invloves a scripting node to get the object ID.
Ben
10-18-2012 11:00 AM
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
10-18-2012 11:17 AM
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"?
10-19-2012 03:07 AM
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