Jump to content

Bitten in the butt by the 2 button dialog


Recommended Posts

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. cool.gif

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...throwpc.gif

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... oops.giffrusty.giffrusty.giffrusty.gif

-John

  • Like 1
Link to comment
I then patted myself on the back for making a safer UI. cool.gif

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.

Link to comment

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

Link to comment

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.   

Link to comment

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...

Link to comment

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 ......

Link to comment

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   :frusty: 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.

Link to comment

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?

Link to comment

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.

Link to comment

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.

Link to comment

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.

Link to comment

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.

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.