Comparison of references failed

[gerh]

---

@JÞB wrote:

Create your references from the terminal and avoid the strange cast that occurs when "Relinking" a "Dropped VI Server" (Default, "this vi"class, VI VI) to a control ref of a type def 2011 - 2012preSP1

---

For my understanding the references created from the terminal contain the strange cast, because they can't be found by selecting "Find / References". That works only after a "Relink".

The main issue is the code breaks silently if somebody accidentally applies a relink.

Updating Labview is no option for near future - it's quite a large workload to keep versions consistent.

Like noticed above, a workaround would be to compare against some properties instead of the references. I just don't want to use the label or the caption because they can change. The only need is, it must be unique for all controls in the cluster.

Have You any suggestions?

[P@Anand]

How about using the control index property? Its not going to change even if you add controls to your UI.

[JÞB]

OK, I understand the need to maintain versions.  The bug is pretty specific and you have already found most of the behavior that is undesireable.  Specifically note that the "Bad" references only fail the comparisons equal and not equal and any property or method still works.

SO, a workaround is very doable! (It may be less than optimal but it is doable!)

What is the exact use case that we need to find the workaround for?  Bare in mind that "Developer Pain" is not something we can work around the goals are to:

A) generate code that functions as intended

B) Teach the developers that may see this that it exists and to be aware of it.

[gerh]

OK, let's look into the code ...

This three use-cases are in focus of the workaround:

1) The user interface is configurable by a INI-file. To keep the main VI clean, a subVI takes a reference and makes the dirty job. For now I decided to keep the first implementation - which is to compare against the labels instead of the references. It's OK as long as nobody fiddles with the label texts.

Here is the snippet:

2) Enable key access if and only if the focus is on the addressed control:

This is the most critical part because the cluster is typedefed. FocusObj gives a reference of type GObject, so the cluster reference is downcasted before comparison. The code works, but it needs caution not to break it silently by accident.

3) Share code in an event structure ...

Here a workaround is easy - just split into separated event cases for each control (this is an issue of code duplication which is just not pretty).

So the case 2) is the main issue. The most clean way would be the comparison against references - except for the few cases described earlier in this thread. Alternatively I could compare against the label in general but I would be glad for any suggestions to make it in a cleaner way.

@ P@Anand:

Just to remind ... captions (also sometimes labels) and indices of cluster elements are in focus of the GUI-designer. So they may change without any prior warning.

Addendum:

Some more tests have shown this issue applies only to complex typedefed GUI elements like clusters or arrays but not to primitives like DBL or Boolean. Without the typedef there is no problem at all.

[JÞB · Accepted solution]

That sounds like some darned good work!  great sleuthing and quite a bit of patience to get working code.  And you posted summaries with examples noting where the workarounds could break for future developers.

For workaround 1  Labels are not run-time writable so the caution to code maintainers to NOT fiddle with them seams suitable even if it causes developer constraints it wont risk deployed code.  Not ideal from a purist perspective but probably a good solution given the problem scope.  If the maintainer of the code can't read the comments....... 

Same with Case 2.  caution the maintainer, make the code work, ship the solution, the user is not impacted so send the invoice and get paid!

At 3 the code smell is a bit ripe with the duplicated code.... Again, with the constraints you worked against I would pass it in any code review.

Well Done and Thanks for the clear post!  my hat is off to you my friend!

[parthabe]

---

@gerh wrote:

@ P@Anand:

Just to remind ... captions (also sometimes labels) and indices of cluster elements are in focus of the GUI-designer. So they may change without any prior warning. 

---

Use Cluster Class ID. Somewhere long back, I've read that Class IDs won't be changed by NI, but Class Names could be.

[P@Anand]

---

@parthabe wrote:

---

@gerh wrote:

@ P@Anand:

Just to remind ... captions (also sometimes labels) and indices of cluster elements are in focus of the GUI-designer. So they may change without any prior warning. 

---

Use Cluster Class ID. Somewhere long back, I've read that Class IDs won't be changed by NI, but Class Names could be.

---

Correct, but if I place the same cluster 2 times both will give the same class ID which is not the desired.

[parthabe]

Class ID/Name is related to the (data)type of the Control/Indicator, NOT the number of instances it is present in your VI. If you want to have/find/compare that uniqueness, then you must use the Label property, which is not editable at run-time. 

BTW, what did you mean by the "control index property"? 

[P@Anand]

---

@parthabe wrote:

Class ID/Name is related to the (data)type of the Control/Indicator, NOT the number of instances it is present in your VI. If you want to have/find/compare that uniqueness, then you must use the Label property, which is not editable at run-time. 

BTW, what did you mean by the "control index property"? 

---

Its the normal Control Index property available for any control/indicator. Why I suggested is to have the uniqueness since it will never change  as long as you remove the control/indicator.

[parthabe]

Can you post a snapshot of what you mean? I still dont understand where the Index property available for any control/indicator.