Bitten in the butt by the 2 button dialog

[John Lokanis]

Just thought I would pass this simple observation when using the 2 button dialog.

I created a dialog where I wanted to warn the user to be careful when selecting a certain operation. In order to make sure they did not accidentally select OK, I reversed the messages so the cancel would be the one that defaulted to having it's key focus set to true. Then, I used the 'T button?' output to select the case and put the code to do the action in the false case. I then patted myself on the back for making a safer UI.

Along comes the "user" and they select this operation from the menu then panic thinking the computer will explode if the do the operation. But, instead of pressing the 'abort' button, they CLOSE THE DIALOG BOX! Which, of course returns a FALSE for the 'T button?' and the code is executed...

Now, I know I am a fool for not seeing this possibility, but I just thought I would share so perhaps someone else doe not make the same mistake I did...

-John

[Darren]

"if you try to idiot proof your UI, they will build a better idiot..."

I foresee myself quoting this many times in the future...

-D

[crelf]

I then patted myself on the back for making a safer UI.

Ahhh yes - the close button I've seen many many less-than-savvy users click that button instead of "save/cancel". Personally, I think that having it there on dialogs like that is unintuative, and there should be an option to remove it. In those cases, I use our own reuse dialog without the close button.

[PaulG.]

This is funky behavior for a primitive. I've seen more than one bug caused by a close VI button accessible to the user. I would rather write my own VI and leave this "feature" out.

[Tim_S]

I get the opportunity to watch real users of all levels (including one who I had to teach how to turn on a PC, and yes, we do put such with circles and arrows and a paragraph in the manuals). Everyone uses the close window X instead of File->Exit or a conveniently placed OK, return or exit button. I've found this to be true with only a few individual exceptions.

Tim

[jcarmody]

People expect a close button; the red "X" makes them feel safe.  There's the feeling that "If I don't like the options the program gives me, I can always cancel." I don't take it away from them, I handle it.  This way the see what they're accustomed to seeing.   

[John Lokanis]

Well, just finished replacing all calls to the two button dialog with the three button dialog that can disable the close button and/or differentiate between button presses and the close window button. I think NI needs to update the primitive with something better.

One other 'note' about these one and two button primitives: they are not root-loop safe. In other words, if one pops up and there is no one around to click on it, all your parallel code in the background will freeze as soon at it hits a function that requires root loop access, like VI server calls to open a dynamic VI. Fun! (FWIW, dropping down a menu and leaving it unselected will do the same thing)

Final note: the three button dialog is not reentrant, in case you ever needed it to be...

[Yair]

For things where you really want to make sure the user notices it, you're better off with a custom dialog which looks different (large, bold, red font tends to work).

[LHarris]

For things where you really want to make sure the user notices it, you're better off with a custom dialog which looks different (large, bold, red font tends to work).

Depends on the users - large bold red font can be enough to invoke panic & constant calls to support ......

[jcarmody]

For things where you really want to make sure the user notices it, you're better off with a custom dialog which looks different (large, bold, red font tends to work).

I had a    situation yesterday where an operator ignored the large, bold, black-font-on-yellow-background dialog that told them they were doing something wrong.  When a downstream process failed they told the line-leader that they ignored the warning because they "thought it was all right".

You can't fix stupid everything.

[Aristos Queue]

Final note: the three button dialog is not reentrant, in case you ever needed it to be...

Of course it is not reentrant. When would you ever be able to show two modal dialogs at the same time? It never needs to run in parallel with itself, so there's no reason it should be reentrant.

[John Lokanis]

Of course it is not reentrant. When would you ever be able to show two modal dialogs at the same time? It never needs to run in parallel with itself, so there's no reason it should be reentrant.

Yes. Funny thing is, the native one and two button dialogs ARE reentrant. So, I was merely pointing out that difference, in case someone had a good reason to display two modal dialogs at once and tried replacing the native ones with the Three Button Dialog.

Can you offer any insight into why the native ones are reentrant? And why they are not root loop safe?

[Yair]

Can you offer any insight into why the native ones are reentrant? And why they are not root loop safe?

Presumably NI just calls the standard dialog window from the OS (e.g. MessageBox in Windows) and has little control over how it behaves.

[asbo]

Presumably NI just calls the standard dialog window from the OS (e.g. MessageBox in Windows) and has little control over how it behaves.

That really shouldn't change whether or not the VI itself is reentrant, though.

[Yair]

It's not a VI, but a primitive, which presumably means a lot as far as reentrancy configuration is concerned.

FWIW, I'm not saying that they shouldn't be locked, just that it may not be as simple as going into a VI and changing it to be non-reentrant.

[asbo]

It's not a VI, but a primitive, which presumably means a lot as far as reentrancy configuration is concerned.

FWIW, I'm not saying that they shouldn't be locked, just that it may not be as simple as going into a VI and changing it to be non-reentrant.

Touché. For whatever reason, I had it in my head that it was a VI - great point.