LabWindows/CVI

cancel
Showing results for 
Search instead for 
Did you mean: 

label bug

Solved!
Go to solution

Hi,

 

in CVI 9.0 (and XP64), using a GUI generated by the GUI editor, a problem occurs if the control attribute ATTR_CTRL_MODE of a control is changed programmatically from VAL_HOT to VAL_INDICATOR. In the GUI, the control mode is defined as HOT. The problem is that the label position is shifted to the left in INDICATOR mode; changing the value back to HOT results in the correct (initial) position. This happens for numeric controls and ring controls (I haven't tried others). Thus the shifted label may overlap other controls.

I cannot tell if this is specific to CVI 9.0, as usually I build my controls programmatically. This time I used the GUI editor for a faster test build...

 

By the way, I did not find an opportunity to submit such problems/bugs than this forum. Is this the intended place?

 

Wolfgang

0 Kudos
Message 1 of 3
(3,130 Views)
Solution
Accepted by topic author Wolfgang

Hi Wolfgang,

 

It's perfectly okay to submit bug reports in this forum.

 

Free-floating labels are associated with the main part of a control in a way such that when the master part changes position, the label is automatically repositioned. You see this, for example, when you move a control and the label also moves with it. What happens when you change a numeric or ring control to be an indicator is that the inc/dec arrows on the left of the control disappear, and the input area of the control (which is the master part of the control) grows leftward to occupy the empty space. This leftward movement of this part of the control causes a label that is on the left of the control (as opposed to, say, the top of the control) to also shift leftward in order to maintain the same distance from the master part. By the way. this doesn't just happen when you change the control mode programmatically. You can also see it if you change it in the editor.

 

The workaround for this is to record the position of the label (ATTR_LABEL_LEFT) before you change the control mode, and then set it back to the same position after you change the control mode.

 

I completely agree that this is a scenario in which most people probably wouldn't want the label to move, since the control as a whole isn't really "growing". But because the association is between the label and one specific part of the control, and because that specific part is growing, then this behavior happens as a consequence.

 

Because this behavior has always existed, even if we considered it undesirable we couldn't really change it at this point, since by now it's very likely that there are programs out there that have come to rely on it, and changing the behavior would break backwards compatibility.

 

0 Kudos
Message 2 of 3
(3,118 Views)

Thank you for the explanation. Probably I forgot this fact few years ago when I decided to build GUIs programmatically, using a text message instead of a label. So I will stick to this approach, but may be it would be a possibility to add a 'movable' attribute to the label? This would maintain backward compatibility and solve such 'problems'...?

 

Wolfgang

0 Kudos
Message 3 of 3
(3,090 Views)