Limitations of Filtering String Controls with Key Down

[lvb]

I thought that I would stir up a conversation regarding the proper way to filter string controls for input.

I was attempting to create a code reuse merge VI for filtering a string control and ran into a few important points:

1. The Key Down? event does not detect "repeat" keypresses. For example, if you press and hold any key, the event structure will only fire once. All remaining "repeats" of the character will not trigger an event. Thus, the user can enter any character even if you use the Discard? terminal.
   To solve this, both the Key Down? and Key Repeat? should occur in the same event case.
   
2. Pasting text into the string control will not be captured by the Key Down? event (sounds logical)
   

In summary, it seems that only the "Value Change" event is capable of truly limiting string control input unless there is a way to stop the paste event.

Your opinions and comments are welcome!

[Michael Aivaliotis]

Use "update value while typing" and see how that changes things.

[Aristos Queue]

QUOTE (brianafischer @ Apr 28 2008, 05:59 PM)

In summary, it seems that only the "Value Change" event is capable of truly limiting string control input unless there is a way to stop the paste event.

Pretty much. But if you popup on the string control and enable "Update Value While Typing", you'll get a Value Change event each time the user types a character -- including Key Repeat events -- so you can filter or accept as much as you want. At that point, you probably will probably want to know when the user commits the value, so you'll monitor for Key Down on the Enter key and/or the loss of focus on the control (there's some post some where on LAVA about monitoring for loss of control for exactly this scenario... search around for a while and see what you find).

[lvb]

QUOTE (Michael_Aivaliotis @ Apr 28 2008, 07:11 PM)

Use "update value while typing" and see how that changes things.

Michael,

I have attached a screenshot of the event for my VI. Update Value while Typing is enabled. I have been able to use the Key Repeat? event to stop the issue in item #1, but have not been able to figure out a way to prevent the user from pasting in data and bypassing the event structure. Please let me know if there is a way to do this!

Thanks

http://lavag.org/old_files/monthly_04_2008/post-4274-1209425544.png' target="_blank">

[lvb]

This thread is solved!!! With a little elbow grease, and credit to Ben here, I have a VI that will prevent the user from pasting into a string control.

A few "tricks"

1. The paste command (CTRL+V) is detected by the Menu Selection? (App) event.

2. The good old linux SHIFT+INSERT is not detected through the Menu Selection? (App) event. Not sure why this is inconsistent, but... We can use the Key Down? AND Key Repeat? events to filter this.

Through my testing I have not found a way to paste! Single presses and holding down CTRL+V, SHIFT+INSERT no longer works! Your comments are welcome...

[Michael Aivaliotis]

Not sure why it's a good thing to prevent ctrl+V. This is a very useful UI capability and crippling it is bad I think. Of course it depends on the application. I guess you don't want it here.

I'm not sure why you don't use the "value change" event. It traps everything if "Update Value While Typing" is on. However I must admit I learned something new today. Shift+Insert does not fire a value change but Ctrl+V does. Is this a LV bug? Who the hell, besides probably Ben, uses "Shift+Insert"?

[lvb]

QUOTE (Michael_Aivaliotis @ Apr 29 2008, 01:12 AM)

Not sure why it's a good thing to prevent ctrl+V. This is a very useful UI capability and crippling it is bad I think. Of course it depends on the application. I guess you don't want it here.

I'm not sure why you don't use the "value change" event. It traps everything if "Update Value While Typing" is on. However I must admit I learned something new today. Shift+Insert does not fire a value change but Ctrl+V does. Is this a LV bug? Who the hell, besides probably Ben, uses "Shift+Insert"?

Michael, thanks for the response.

Point #1

I am trying to limit a text box to the following constraints:

• 1st character must be a letter.
  
• 12 characters maximum
  
• Valid characters are: a-z, A-Z, 0-9, _
  

I started this filtering with the mouse down and was more interested in learning about the "quirks" of this approach than the value change. Using the value change, and the string subset commands, I could extract the last character and filter the control.

However, with this approach, there is one issue that I have not solved yet: when pasting a large line of text and filtering (via overwriting the local variable), the pasted text is sometimes displayed for a few msec, which makes it appear to "flash". Do you have a solution to this?

Point #2

QUOTE

Who the hell, besides probably Ben, uses "Shift+Insert"?

Linux users unite!

[Aristos Queue]

QUOTE (Michael_Aivaliotis @ Apr 29 2008, 12:12 AM)

Who the hell, besides probably Ben, uses "Shift+Insert"?

I do. On every Windows app *except* LV it works just fine. Ctrl+insert, shift+insert and shift+delete. Very fast shortcut keys.

[Darren]

QUOTE (Aristos Queue @ Apr 29 2008, 01:30 PM)

I do. On every Windows app *except* LV it works just fine. Ctrl+insert, shift+insert and shift+delete. Very fast shortcut keys.

How are they faster than Ctrl-X/C/V? The X, C, and V keys are all very close to the left Ctrl key and typable with the left hand only.

-D

[Rolf Kalbermatter]

QUOTE (Aristos Queue @ Apr 29 2008, 02:30 PM)

I do. On every Windows app *except* LV it works just fine. Ctrl+insert, shift+insert and shift+delete. Very fast shortcut keys.

Must be standard windows message handling then, overwritten by LabVIEWs less than standard windows message queue handling. I doubt every Windwos application would bother to implement these somewhat weird key shortcuts themself.

Rolf Kalbermatter