SetInputMode moves labels

[Guillaume Dargaud]

Why does SetInputMode move the labels of some numeric controls ?
Take a numeric with inc/dec arrows and a label on _top_.
Disable its input mode and apply it back: the label has moved about 10 pixels to the right !

It's annoying as it breaks the look of the UIR. Is there away to avoid that besides some heavy
handed label location memorisation ?
--
Guillaume Dargaud
http://www.gdargaud.net/
"At the end of Braveheart, William Wallace's last word was 'Freedom!'. When I die, my last words
will probably be more along the lines of: 'Aw, dammit...'." - Eric Spratling.

[LuisG]

Guillaume,

I looked into this, but I couldn't reproduce it. I tried running the following code in the interactive window...

#include
#include
static int panel, ctrl;

panel = NewPanel (0, "test panel", 100, 100, 400, 600);
ctrl = NewCtrl (panel, CTRL_NUMERIC, "numeric", 100, 100);
SetCtrlAttribute (panel, ctrl, ATTR_LABEL_LEFT, 100);
DisplayPanel (panel);
Delay (2.0);
SetInputMode (panel, ctrl, 0);
ProcessDrawEvents();
Delay (2.0);
SetInputMode (panel, ctrl, 1);
ProcessDrawEvents();
Delay (2.0);
DiscardPanel (panel);

...but the label didn't move. Can you try this
in your computer and see if it moves?

If it doesn't move with this code, can you find some relevant difference between this sequence and what you are doing in your code?

Luis
NI

[Guillaume Dargaud]

> I looked into this, but I couldn't reproduce it. I tried running the
> following code in the interactive window...


Correction, it's not SetInputMode, but SetCtrlAttribute with ATTR_CTRL_MODE between VAL_INDICATOR
and VAL_HOT.

I couldn't get direct code to reproduce the bug, but a little project does (files attached).

See how the label for one control comes back to its original location while the other one doesn't
?

--
Guillaume Dargaud
http://www.gdargaud.net/
"Not all men who drink are poets. Some of us drink because we aren't poets."

[LuisG]

Okay, I found out what's going on.

CVI has some fairly complicated internal rules for determining what happens to free-floating parts of controls (such as labels, digital displays, graph legends), whenever another part of the control changes position. The internal parts of controls have master-slave relationships, and it's not always obvious how one affects the other.

In this case, the impetus is given by the fact that the inc/dec arrows of the numeric control are hidden whenever you turn the control into an indicator. This results in the frame of the control growing to the left in order to fill up the new space. The frame is the master part for the label, so this in turn will "influence" the label's position. This influence isn't always easy t
o explain, but in this case, the reason your label is moving is because it has a slight overlap with the frame of the control itself. In the .uir you attached, the bottom of the label is at position 96, and the top of the frame is also at position 96. If you move the label a single pixel higher, then there won't be an overlap any more, and the label will not shift if the frame grows to the left.

Like I said, it's a bit hard to explain, although it does make sense, if one is to consider all the possible scenarios. Hopefully you'll be able to move the label a bit, and then you won't have to worry about it any more.

Luis

[Guillaume Dargaud]

> Like I said, it's a bit hard to explain, although it does make sense,

In other words, it's a 'feature'... 😉
I wrote a very simple wrapper function that just get the label left, change the control style and
reapply the control left.

Thanks for the detailed explanation.
--
Guillaume Dargaud
http://www.gdargaud.net/
"A one-question geek test. If you get the joke, you're a geek: Seen on a California license
plate on a VW Beetle: 'FEATURE'..." - Joshua D. Wachs - Natural Intelligence, Inc.