KeyCode/Shift values to ASCII Code

  • Thread starter Thread starter Ronald Dodge
  • Start date Start date
R

Ronald Dodge

Maybe I should of asked in here. Before answering this question, be sure to
read the entire message. Reason being, you may think of an answer of which
I stated later in this message as to why I don't necessarily want to use
that solution or why it won't work. Is there a function/API to convert the
KeyCode and Shift values to an ASCII code?

First thing you may think about is the KeyPress Event, but due to some
limitations that it poses, I have decided to use the KeyDown Event for my
"General Data Validation" level. I have also created my own custom version
of the Validate Event and CausesValidation Property for my "Specific Data
Validation" level, so as users not only can use the keyboard to move around,
but also be able to use the mouse to be able to move around as there are a
minor few command buttons that the user may want to execute, but yet, data
validation checking may not be desired, thus why I have created my own
custom version of the Validate Event and CausesValidation property within
VBA that VB has. Now given this particular question is asked mainly for a
specific aspect of the "General Data Validation" level, it should rightfully
stay in the same group as the rest of the "General Data Validation" level
rather than creating a new data validation check level.

Now, I could create my own custom function to do this, but why duplicate
work if it's not needed?

There are still a few things I don't like about how the KeyCode works as I
would rather see it more like how the scancode works in C programming, but
that's just something I have to deal with.

TIA for any help that anyone may be able to provide.
 
Hi Ronald,

AFAIK there's no built in function for this.

Detailed documentation on the KeyDown and KeyUp events seems to have
been left out of Help in Access 2000 and later. Basically, the Shift
argument is a bitfield in which
Bit 1 is set if a Shift key was depressed
Bit 2 Control
Bit 3 Alt
In Access VBA these values are represented by the constants
acShiftMask = 1
acCtrlMask = 2
acAltMask = 4
For most keys, KeyCode returns the ASCII code of the character in
question (upper-case for keys A to Z). There is also a pre-declared set
of vbKeyXX constants (see the Object Browser).

I don't know how to make these events distinguish between left and right
shift keys or (and more importantly with international keyboards) Alt
and AltGr. I suspect you'd need to use the API for that; perhaps you
could call the GetKeyState() or GetKeyboardState() API function from
within the KeyDown event procedure.

Maybe I should of asked in here. Before answering this question, be sure to
read the entire message. Reason being, you may think of an answer of which
I stated later in this message as to why I don't necessarily want to use
that solution or why it won't work. Is there a function/API to convert the
KeyCode and Shift values to an ASCII code?

First thing you may think about is the KeyPress Event, but due to some
limitations that it poses, I have decided to use the KeyDown Event for my
"General Data Validation" level. I have also created my own custom version
of the Validate Event and CausesValidation Property for my "Specific Data
Validation" level, so as users not only can use the keyboard to move around,
but also be able to use the mouse to be able to move around as there are a
minor few command buttons that the user may want to execute, but yet, data
validation checking may not be desired, thus why I have created my own
custom version of the Validate Event and CausesValidation property within
VBA that VB has. Now given this particular question is asked mainly for a
specific aspect of the "General Data Validation" level, it should rightfully
stay in the same group as the rest of the "General Data Validation" level
rather than creating a new data validation check level.

Now, I could create my own custom function to do this, but why duplicate
work if it's not needed?

There are still a few things I don't like about how the KeyCode works as I
would rather see it more like how the scancode works in C programming, but
that's just something I have to deal with.

TIA for any help that anyone may be able to provide.
Click to expand...

John Nurick [Microsoft Access MVP]

Please respond in the newgroup and not by email.
 
Well as I mentioned before, there are few cases where I would like to be
able to convert the KeyCode and the Shift code to ASCII character code
including the punctuations, and other keys that does have ASCII codes.
However, I also know that even depending on what either the numlock and/or
caps lock keystate is (where GetKeyState comes into play), it can also mean
the difference between the shifted character and the unshifted character.
Example, if Caps Lock is on, when someone pressed Shift-A, it actually
returns a lower case A (a). What if I wanted to return the ASCII code for
the colon (:) for when someone pressed the Shift Key and the key that
correspond to the colon (KeyCode of 186 and Shift value of 1). Of course,
the Caps lock toggle key value would only affect the letters while the
numlock affects the numbers and decimal key on the numpad. Not only that, I
already have the values of all 4 toggle keys, and 3 modifier keys (20, 45,
144, 145 for caps, insert, numlock, and scroll lock while it's 16, 17, 18
for Shift, Ctrl, and Alt) from when I had setup my other general data
validation checks. Now, I have moved into the area of validating dates and
times just to be sure it even meets the format requirements based on locale
settings, so here's what I was thinking, if I take the KeyCode and the Shift
value, convert that to the ASCII code, which then gets converted to the
actual character, then compare that to the locale date/time separator (which
ever separator that it's being compared to) that is in the regional
settings, then I would just use the function that's already included, but
from what I get the feeling, there is no function (at least known to the
group) that has already been created and made available, thus would lead me
to believe I have to create my own function, but then in that case, it would
only be US locale version, thus has me actually thinking to go in another
direction, if this isn't already available.

--
Ronald R. Dodge, Jr.
Production Statistician
Master MOUS 2000
John Nurick said:
Umm. Your original question referred to the arguments of the KeyDown
event procedure:
Is there a function/API to convert the
KeyCode and Shift values to an ASCII code?
Click to expand...

You can get all ASCII characters on most if not all keyboards just by
testing KeyCode and Shift, so you must be trying to do something else.

I'm not competent to follow you into the API keyboard functions, but if
you care to describe your actual problem (as opposed to particular
difficulties with one possible solution), people here may be able to
suggest a more VBA-friendly approach.

Thank you for the response. I already knew about the different Shift values
(0-7 for no modifier keys pressed, any of the modifier keys pressed or some
combination of the modifier keys pressed). In addition, I use the
GetKeyState in combination with the Shift value as that can also make a
difference.

The closest that I seen so far is the MapVirtualKeyEx function, but even
that doesn't get all of the ASCII characters as it states:

"For the third type of mapping, uppercase letters A through Z are returned
for VK_A through VK_Z. ASCII characters are returned for the top-row numeric
keys VK_0 through VK_9. For punctuation and dead keys in the main part of
the keyboard, the unshifted character will be returned."

Here's a link to the references of the different Win 95 Keyboard Drivers

http://msdn.microsoft.com/library/en-us/w98ddk/hh/w98ddk/keycnt_4iic.asp

I also looked at a few other functions like ToAsciiEx, but not really sure
what I need to put in for all of the arguments. I know I need to use the
KeyCode as the first argument, guessing it takes the shift value for the
second argument, not really sure for the next 3 arguments, and then the last
argument is the LCID which I already have a constant for that.
Click to expand...

John Nurick [Microsoft Access MVP]

Please respond in the newgroup and not by email.
Click to expand...
 
Ronald,

I hope you'll forgive me for suspecting that you may have got a bit too
close to the trees to see the wood. Is it really really necessary to do
data validation on the KeyDown event? I'm struggling to think of a
situation in which that would be necessary. Normally I'd do the
validation on BeforeUpdate, and only use the keyboard events (usually
KeyPress) to limit the characters that could be input.

For dates and times, I'm not sure what the point is in requiring the
user to adhere to a specific format when inputting data. CDate() and
similar functions can recognise a wide range of date strings; once
converted to an Access date/time value, textboxes and the Format()
function can display it in the locale-dependent formatting.

But if you actually do need to "read the keyboard" I suggest that you
search in the Visual Basic forums. It's much more likely that someone in
that world will have written the function you're looking for, and (as a
rule) VB functions using the Windows API need little or no modification
to work in VBA.

Well as I mentioned before, there are few cases where I would like to be
able to convert the KeyCode and the Shift code to ASCII character code
including the punctuations, and other keys that does have ASCII codes.
However, I also know that even depending on what either the numlock and/or
caps lock keystate is (where GetKeyState comes into play), it can also mean
the difference between the shifted character and the unshifted character.
Example, if Caps Lock is on, when someone pressed Shift-A, it actually
returns a lower case A (a). What if I wanted to return the ASCII code for
the colon (:) for when someone pressed the Shift Key and the key that
correspond to the colon (KeyCode of 186 and Shift value of 1). Of course,
the Caps lock toggle key value would only affect the letters while the
numlock affects the numbers and decimal key on the numpad. Not only that, I
already have the values of all 4 toggle keys, and 3 modifier keys (20, 45,
144, 145 for caps, insert, numlock, and scroll lock while it's 16, 17, 18
for Shift, Ctrl, and Alt) from when I had setup my other general data
validation checks. Now, I have moved into the area of validating dates and
times just to be sure it even meets the format requirements based on locale
settings, so here's what I was thinking, if I take the KeyCode and the Shift
value, convert that to the ASCII code, which then gets converted to the
actual character, then compare that to the locale date/time separator (which
ever separator that it's being compared to) that is in the regional
settings, then I would just use the function that's already included, but
from what I get the feeling, there is no function (at least known to the
group) that has already been created and made available, thus would lead me
to believe I have to create my own function, but then in that case, it would
only be US locale version, thus has me actually thinking to go in another
direction, if this isn't already available.
Click to expand...

John Nurick [Microsoft Access MVP]

Please respond in the newgroup and not by email.
 
As I mentioned before, some data validation though general by nature can be
done as the user is typing the information. In addition, in some cases,
there may be times when just the numpad is being used, thus I also added a
couple of features to help make data entry easier without necessarily having
to switch back and forth either between the qwerty keyboard and the numpad
or between the numpad and the mouse as those kinds of movements also takes
up extra time. This sort of adjustment can not take place in the KeyPress
Event and was thought to best take place in the KeyDown Event. Of course, I
have modulated my code so as the only line that's in the KeyDown Event of
the controls is a function call with the necessary arguments.

--
Ronald R. Dodge, Jr.
Production Statistician
Master MOUS 2000
John Nurick said:
Ronald,

I hope you'll forgive me for suspecting that you may have got a bit too
close to the trees to see the wood. Is it really really necessary to do
data validation on the KeyDown event? I'm struggling to think of a
situation in which that would be necessary. Normally I'd do the
validation on BeforeUpdate, and only use the keyboard events (usually
KeyPress) to limit the characters that could be input.

For dates and times, I'm not sure what the point is in requiring the
user to adhere to a specific format when inputting data. CDate() and
similar functions can recognise a wide range of date strings; once
converted to an Access date/time value, textboxes and the Format()
function can display it in the locale-dependent formatting.

But if you actually do need to "read the keyboard" I suggest that you
search in the Visual Basic forums. It's much more likely that someone in
that world will have written the function you're looking for, and (as a
rule) VB functions using the Windows API need little or no modification
to work in VBA.

Well as I mentioned before, there are few cases where I would like to be
able to convert the KeyCode and the Shift code to ASCII character code
including the punctuations, and other keys that does have ASCII codes.
However, I also know that even depending on what either the numlock and/or
caps lock keystate is (where GetKeyState comes into play), it can also mean
the difference between the shifted character and the unshifted character.
Example, if Caps Lock is on, when someone pressed Shift-A, it actually
returns a lower case A (a). What if I wanted to return the ASCII code for
the colon (:) for when someone pressed the Shift Key and the key that
correspond to the colon (KeyCode of 186 and Shift value of 1). Of course,
the Caps lock toggle key value would only affect the letters while the
numlock affects the numbers and decimal key on the numpad. Not only that, I
already have the values of all 4 toggle keys, and 3 modifier keys (20, 45,
144, 145 for caps, insert, numlock, and scroll lock while it's 16, 17, 18
for Shift, Ctrl, and Alt) from when I had setup my other general data
validation checks. Now, I have moved into the area of validating dates and
times just to be sure it even meets the format requirements based on locale
settings, so here's what I was thinking, if I take the KeyCode and the Shift
value, convert that to the ASCII code, which then gets converted to the
actual character, then compare that to the locale date/time separator (which
ever separator that it's being compared to) that is in the regional
settings, then I would just use the function that's already included, but
from what I get the feeling, there is no function (at least known to the
group) that has already been created and made available, thus would lead me
to believe I have to create my own function, but then in that case, it would
only be US locale version, thus has me actually thinking to go in another
direction, if this isn't already available.
Click to expand...

John Nurick [Microsoft Access MVP]

Please respond in the newgroup and not by email.
Click to expand...
 
Well anyhow, You may have posed a good question. Reason why I mentioned
"May", it seems as though lots of Access Developers haven't really ran into
an issue too much about what happens when a mouse user clicks on a command
button and can't get it to work due to some validation code preventing the
command button to get the focus, but it's this very issue that I don't like
using the BeforeUpdate Event for validation purposes, which means my forms
can't be bound, if I'm going to have data validation. Why it's this very
issue, it's not 100% of the time you want that exact same method of data
validation check to take place whenever a user clicks on a command button.

Why use the KeyDown Event instead of the BeforeUpdate Event?

Well this is a 2 part answer:

Part 1:

The BeforeUpdate Event is ran every single time an update is about to take
place including when a user wants to click on a command button that doesn't
require the previous control to be validated in it's normal way (I.e. Either
clicking on a "Help" command button or a command button that reset's the
form.), so to get around this issue, I have created my own CausesValidation
Property similation and Validate Event.

Part 2:

It's best to catch errors as soon as possible, so from the stand point of
general format requirements, the KeyDown Event is the best place to catch
those types of issues while the Validate Event (that I have custom created
to get around the mouse user friendly issue within Access - See Part 1
above) catches the specific validation errors.

Results:

For this to work, I can not work with bound forms due to the very fact of
how the Events works in Access on bound forms, which makes it not mouse user
friendly (the sole reason why I don't use bound forms). It has thus far
proven to be working out, though some standardization is required, but for
the most part, there's not much to it that's really different, other than
for the fact that the error messages are designed to show up in a label on a
form rather than in a message box, and messages generally tends to be more
user friendly than what Access would have it by default.

This has been coded for 3 months now and I have for the last 3 months been
worked on Form Behavior issues. I have lately finished up the form behavior
issues and moved onto the specific forms, and even that's working out pretty
good up to this point of time.

As you may have guessed, I have a DB program planned out that I spent quite
a few hours (maybe a couple thousand, but not sure as I do other things too
other than just programming), of which I would eventually like to see this
go into a SQL Server Environment, but I don't have the say so in that.
During this time, I basically felt that I needed to see about developing
some basic things for the base foundation of my DB program and start testing
to see how things works out. Over the last 6 months, I have learned a lot
of in depth stuff with Access and DAO programming of which before I could
take it to SQL Server, I will have to get the DAO programming converted to
ADO programming. At this time though, my biggest focus is to get the main
part of my DB program completed (at least the first version of it) and
implemented. That may mean it will have to fore go some things for the time
being, but that doesn't mean it can't be planned for. However, with this
first version, I still require the strict data validation and for my
internal users to use the program, it has to be user friendly of which a lot
of them are more or less mouse users that only uses the keyboard for things
that can't be used with the mouse too easily.

--
Ronald R. Dodge, Jr.
Production Statistician
Master MOUS 2000
John Nurick said:
Ronald,

I hope you'll forgive me for suspecting that you may have got a bit too
close to the trees to see the wood. Is it really really necessary to do
data validation on the KeyDown event? I'm struggling to think of a
situation in which that would be necessary. Normally I'd do the
validation on BeforeUpdate, and only use the keyboard events (usually
KeyPress) to limit the characters that could be input.

For dates and times, I'm not sure what the point is in requiring the
user to adhere to a specific format when inputting data. CDate() and
similar functions can recognise a wide range of date strings; once
converted to an Access date/time value, textboxes and the Format()
function can display it in the locale-dependent formatting.

But if you actually do need to "read the keyboard" I suggest that you
search in the Visual Basic forums. It's much more likely that someone in
that world will have written the function you're looking for, and (as a
rule) VB functions using the Windows API need little or no modification
to work in VBA.

Well as I mentioned before, there are few cases where I would like to be
able to convert the KeyCode and the Shift code to ASCII character code
including the punctuations, and other keys that does have ASCII codes.
However, I also know that even depending on what either the numlock and/or
caps lock keystate is (where GetKeyState comes into play), it can also mean
the difference between the shifted character and the unshifted character.
Example, if Caps Lock is on, when someone pressed Shift-A, it actually
returns a lower case A (a). What if I wanted to return the ASCII code for
the colon (:) for when someone pressed the Shift Key and the key that
correspond to the colon (KeyCode of 186 and Shift value of 1). Of course,
the Caps lock toggle key value would only affect the letters while the
numlock affects the numbers and decimal key on the numpad. Not only that, I
already have the values of all 4 toggle keys, and 3 modifier keys (20, 45,
144, 145 for caps, insert, numlock, and scroll lock while it's 16, 17, 18
for Shift, Ctrl, and Alt) from when I had setup my other general data
validation checks. Now, I have moved into the area of validating dates and
times just to be sure it even meets the format requirements based on locale
settings, so here's what I was thinking, if I take the KeyCode and the Shift
value, convert that to the ASCII code, which then gets converted to the
actual character, then compare that to the locale date/time separator (which
ever separator that it's being compared to) that is in the regional
settings, then I would just use the function that's already included, but
from what I get the feeling, there is no function (at least known to the
group) that has already been created and made available, thus would lead me
to believe I have to create my own function, but then in that case, it would
only be US locale version, thus has me actually thinking to go in another
direction, if this isn't already available.
Click to expand...

John Nurick [Microsoft Access MVP]

Please respond in the newgroup and not by email.
Click to expand...
 
Back
Top