LabVIEW
Labview events and disabled controls on a tab control
Hiya,
OK. No offence to the general population, but sometimes users do things with your program that you don't really expect. Ever written a program that does something simple? Example I wrote (useing cvi here) that put a time and date into a string on the front panel. I had users who tried to change the value in that box because the computer clock didn't match the time on their wrist watch. Program defensively, and you can catch for almost anything.
The next example is a little more realistic - what if you have a touch screen. What if you have a user handling system that automatically enables and disables controls by passwords. What if someone wants to do something, but they're not logged in. Ever tried to hit a menu on a touch screen? What about if the system is left alone, and set to automatically log a user out if it's not in use? (Just in case the user has forgotten to log out and doesn't want to allow users with less access rights to do certain things).
And finally - what if, as a programmer, your customer said that was the behaviour they wanted?
Counter intuative becomes a way of life when you deal with the multitude of us humans, who always search for a way to do something different. I've seen a lot of software test procedures, that have been written for military applications, and they're always designed to stress the software to breaking point by doing things out of the ordinary. It's not to be awkward, it's just so that a new user doesn't have to go through the whole of the manual looking for the caveats.
I agree in principle that there are times when you can change the way the program works by giving the user a login button, and getting them to login first, and then they'll have access to particular options. But it's just so nice when you can give the user extra information, like - "Go fetch your supervisor to gain administrator access" when they do try something "counter intuative"
Clicking on a disabled item and expecting a reaction is down to how you program. If you don't want a reaction, then check to see if it's disabled, and ignore it, but please don't take away the ability to do this.
Try writing a handler that doesn't need multiple transparent overlayed controls to catch the disabled button on the front panel, and without sitting in a permanent polling loop. It's not impossible, but it's complex. (Or maybe someone has an answer there that will make us all look dumb).
That's all - programming should be fun - that's one of the reasons behind LabVIEW.
2 cents worth plus 2.
S.
OK. No offence to the general population, but sometimes users do things with your program that you don't really expect. Ever written a program that does something simple? Example I wrote (useing cvi here) that put a time and date into a string on the front panel. I had users who tried to change the value in that box because the computer clock didn't match the time on their wrist watch. Program defensively, and you can catch for almost anything.
The next example is a little more realistic - what if you have a touch screen. What if you have a user handling system that automatically enables and disables controls by passwords. What if someone wants to do something, but they're not logged in. Ever tried to hit a menu on a touch screen? What about if the system is left alone, and set to automatically log a user out if it's not in use? (Just in case the user has forgotten to log out and doesn't want to allow users with less access rights to do certain things).
And finally - what if, as a programmer, your customer said that was the behaviour they wanted?
Counter intuative becomes a way of life when you deal with the multitude of us humans, who always search for a way to do something different. I've seen a lot of software test procedures, that have been written for military applications, and they're always designed to stress the software to breaking point by doing things out of the ordinary. It's not to be awkward, it's just so that a new user doesn't have to go through the whole of the manual looking for the caveats.
I agree in principle that there are times when you can change the way the program works by giving the user a login button, and getting them to login first, and then they'll have access to particular options. But it's just so nice when you can give the user extra information, like - "Go fetch your supervisor to gain administrator access" when they do try something "counter intuative"
Clicking on a disabled item and expecting a reaction is down to how you program. If you don't want a reaction, then check to see if it's disabled, and ignore it, but please don't take away the ability to do this.
Try writing a handler that doesn't need multiple transparent overlayed controls to catch the disabled button on the front panel, and without sitting in a permanent polling loop. It's not impossible, but it's complex. (Or maybe someone has an answer there that will make us all look dumb).
That's all - programming should be fun - that's one of the reasons behind LabVIEW.
2 cents worth plus 2.
S.
Hi all,
you know what I said about there might be an elegant solution that I was missing - here it is. (well I think it's kinda elegant. ok so it's not elegant, but it's another possibility that should be consistent for future versions....
Not ideal, as you have to handle buttons in groups, but it does at least allow you to use events again, reasonably sensibly. - Not easily expandable either.
Guess it's just another option.
S.
you know what I said about there might be an elegant solution that I was missing - here it is. (well I think it's kinda elegant. ok so it's not elegant, but it's another possibility that should be consistent for future versions....
Not ideal, as you have to handle buttons in groups, but it does at least allow you to use events again, reasonably sensibly. - Not easily expandable either.
Guess it's just another option.
S.
Hi,
You said it exactly -
"Secondly, If I saw a disabled control, I would not click on it, and I wouldn't receive your intended message anyway."
There are other people who will press the button. I like the idea of useing the tip-strip, though it doesn't trigger anything like the ability to automatically bring up a login prompt, but then again the program could be re-designed. Also, the cursor isn't really in existence on a touch screen - what I mean is, it's designed to be pressed, not drag the cursor over the control and then hit a control, so tip-strips won't work for this case unless you've already clicked on the item.
I think we'll let this one go, agree to disagree, and see what National Instruments do in future versio
ns.
Remember what sparked this off was a need to get consistent behaviour between events on the panel, and events on a tab control.
Thanks
S.
You said it exactly -
"Secondly, If I saw a disabled control, I would not click on it, and I wouldn't receive your intended message anyway."
There are other people who will press the button. I like the idea of useing the tip-strip, though it doesn't trigger anything like the ability to automatically bring up a login prompt, but then again the program could be re-designed. Also, the cursor isn't really in existence on a touch screen - what I mean is, it's designed to be pressed, not drag the cursor over the control and then hit a control, so tip-strips won't work for this case unless you've already clicked on the item.
I think we'll let this one go, agree to disagree, and see what National Instruments do in future versio
ns.
Remember what sparked this off was a need to get consistent behaviour between events on the panel, and events on a tab control.
Thanks
S.
