Bad Idea: Making default behavior of "built in mouse wheel support" set to on key focus

[thutch79]

This is just a little rant....

I love new features in Labview, but setting them to be on automatically when they can generate unexpect behaviour is really a bad idea. We recently moved from 2012 to 2013. Suddenly, I have users saying "values are changing and I don't know why". Turns out they were changing a value in a numeric, then attempting to scroll away. Why on earth would NI make this the default behavior??? Luckly for us the value change wasn't too bad but I could think of a few places that a sudden, unplanned change in a numeric could have ruined an experiment.

Off to do alot of work to undo this....

[Sam2004mai]

It will be helpful to post an example where this problem happens, i never noticed sush behavior.

[jcarmody]

I wonder how large your Front Panel is that it's necessary to scroll...

[thutch79]

Very simple example....I just placed a stock numeric on the front panel.

[Edit] Of course, this is only an issue in LV 2013.

[thutch79]

---

@jcarmody wrote:

I wonder how large your Front Panel is that it's necessary to scroll...

---

Yes....I understand, I suck at UI design. Thanks for the input.

[Sam2004mai]

I dont see any problem with using my mouse wheel, but i noticed it really depends on have fast you turn the mouse wheel, the fastest you turn it the more it jumps numbers. also it depends on where your cursor is, example: if your cursor is in the hundreds it will increments by hundreds

but all this supposed to be a normal mouse behavior.

[jcarmody]

---

@thutch79 wrote:

Yes....I understand, I suck at UI design. Thanks for the input.

---

I certainly wouldn't say that without seeing it for myself.  😄

[thutch79]

---

@Sam2004mai wrote:

I dont see any problem with using my mouse wheel, but i noticed it really depends on have fast you turn the mouse wheel, the fastest you turn it the more it jumps numbers. also it depends on where your cursor is, example: if your cursor is in the hundreds it will increments by hundreds

but all this supposed to be a normal mouse behavior.

---

I think you missed the point. The problem is now when you put a numeric on the front panel, the increment/decrement by the scroll wheel is enabled by default. If a user doesn't click outside of the control or hit enter, when they try to scroll away, they inadvertantly change the value.

[RTSLVU]

I have noticed this too, but I swear long before 2013.

You should not have to scroll around a user interface to begin with.

If you can not fit a user interface on one screen of the target machine it's time to rethink your interface.

I suggest dividing things up by task and using a tab control.

[thutch79]

---

@RTSLVU wrote:

I have noticed this too, but I swear long before 2013.

You should not have to scroll around a user interface to begin with.

If you can not fit a user interface on one screen of the target machine it's time to rethink your interface.

I suggest dividing things up by task and using a tab control.

---

and this is why I now hate posting in this forum.....

People just love to tell you how you should be doing something, and not focusing on the topic of the thread. If everyone is going to get stuck on the "UI's should not have scroll bars" soap box, see the attached screen shot. This problem arose from a settings pop-up dialog. I could have used tabs, but in this case it makes more sense for the users to move top to bottom in a linear fashion through the process they are setting up.

My point in all this is why would NI make this the default behavior? I like the feature, but it should have been something that a designer has to actively turn on.