Recommend "improvement" in Key Up Events

[Bob_Schor]

I'm using Key Down? and Key Up events to turn the keyboard into a series of switches for a behavioral experiment.  For example, I want the user to push down Caps Lock with the left hand, Return with the right, then use the appropriate hand to do a specified task.  By monitoring Key Down and Key Up events, I can capture the timing of the user's "button sequences" (to the accuracy of Window's clock).

Key Down? provides three indicators of what key is pressed -- Char, which is an I16 representation of the Ascii character (and hence can be "converted" easily into a string one could test, e.g. is this "A"?), VKey, an enum saying if the key is an Ascii character or a "special" key (such as Caps or Return), and ScanCode, which is another I16 that corresponds (somehow) to each key on the keyboard.  There are also boolean indicators that can tell you if Ctrl, Shift, or Alt are being simultaneously pressed.  Of these, the least "transparent" is ScanCode, as there is no obvious way (other than placing a comment on your code) to know that 58 corresponds to CapsLock.

Unfortunately, Key Up only provides ScanCode!  So while I can write "nice" code that can more-or-less self-document that I'm testing for Caps Lock or Return (simply wire VKey to a Case statement, which will allow me to have a case labelled "Caps", pretty obvious, no?), I don't have such functionality with the Key Up event.

Suggestion -- add Char and VKey inputs to the Key Up event!  This will make it "symmetrical" with respect to Key Down?, and will enable producing Key Up code that doesn't need to rely on "magic numbers" (Scan Codes) for specific keys.

Bob Schor

[JackDunaway]

Consider a "translator VI". (This is not an official term... someone please correct my terminology, I just have a concept of the implementation)

You are beginning with a weakly-defined piece of data (ScanCode) which has some mystery since it's not readily human readable. (A weakly-defined piece of data might be an I32 such as the ScanCode, or a flattened string, or a byte array). What you want is a strongly-defined piece of data (an enum, a typedef...) that is clearly readable in the coding environment.

Create a VI whose input is the ScanCode, and the output is a very specific enum or typedef'd cluster - i.e., the translation of the weak datatype. Having translator VI's in your code is also a very reliable way of tracking down where that weak data is translated: just right-click on the translator, and "Find All Instances" (or in the project, "Find All Callers"). It also guarantees that the "dirty work of translating" is only done in one SubVI, and is therefore maintainable since it's not shotgunned all over.

Would this construct help out?

(I have not used Key Up/Key Down enough to have an opinion on whether to vote for this idea, I'm just trying for a quick solution to the problem)

[Darren]

Any idea that has received less than 10 kudos within 10 years after posting will be automatically declined.

[TomOrr0W]

I don't know why I didn't kudo this idea when I first read it (not sure how long ago that was), but I should have - this was an good idea even if I rarely use the key up event itself.  It is unfortunate that it was auto-declined.

Looking at some of the documentation, I think NI intended for users to handle both key down and key up and use the scan code from key down to interpret the key up, but that is a bit of a clumsy workaround.