Downsides to key navigation for shared events?

[thoult]

At a couple of points in my application, I generate modal dialogs that require a user to confirm or cancel.

The application will run either on a touch screen or a system with a keyboard/mouse.

I've written the event structure for the dialog to handle value changes on the boolean switches - clicking confirm will save changes, cancel will discard. I've noticed that some of my operators, given the chance, instinctively use the enter and escape keys for this, as that's a traditional behaviour for many applications.

I can't process key up (including filtering on the button pressed) and control value change events in the same event, so was looking for alternatives.

The simplest one that springs to mind is binding enter to the confirm button and escape to the cancel. The traditional method for doing this is through the right click shortcut menu, but it can also be done via property nodes. I'd prefer the latter so that there's clear documentation that those keys are bound.

I've not used key binding much, but it seems like a simple workaround for things like this. Are there any reasons why it's not seemingly used more?

[nickf]

Hi thoult,

I've always found key binding in LabVIEW a bit lacking. The main limitation is that only special keys can be bound. It's impossbile to bind letters or arrow keys, for example. Also, as you pointed out, key binding settings are not clearly visible in your VIs and are difficult to document.

Even so, key binding works well for simple applications like dialog boxes. For documentation, you might have to resort to adding notes to the code by hand or updating the control tip strips.

For more advanced key navigation, I typically rely on user events to trigger various actions.

[crossrulz]

One trick I have done (haven't really decided if I really like it though) is to have a Key Pressed event.  Inside of there, I figure out which key was pressed and then use the Value (Signaling) property node of the button I want to "bind" that key to.  So if somebody hits the ESC key, I catch that button press and call the Cancel button's Value (Signaling) property.  This will cause the Cancel->Value Changed event to queue up and be called next.

[thoult]

That's something I've done in other situations - such as a DB query running on schedule as well as on demand. You just have to remember that you can't use latching Booleans with value nodes, so you have to delatch the control yourself in the event. Also, you'll need to remember there's another iteration to wait until the final event is processed due to the daisy chaining, but that should be obvious.

Thanks to both of you - I've never really used key binding much, and just wanted to see if there were any aspects I was missing.