Programming Windows API in Mac OS Bootcamp

[karnavor]

Hello,

I am running Windows 7 on a Mac, using Apple's Bootcamp utility, such that the Windows installation is native. However, I am finding some issues when programming the Windows API using Visual Studio, specifically related to user inputs from the keyboard and mouse.

Suppose in a Windows program, the user presses a keyboard key. With a normal PC running Windows, in the WndProc() function, the message argument is WM_KEYDOWN and lParam is typically a number between 0 and 255, representing the key being pressed ("a", "s", "/" etc.). However, when debugging my program, I am finding that lParam is a very large number, eg. 847924401. I cannot find any obvious pattern in these numbers to map them over to the "standard" numbers expected in Windows. Similarly, when a mouse is clicked on the screen, the message is WM_LBUTTONDOWN and lParam indicates the cursor location, but this number is also a very large number, and not what is normally expected under Windows.

Has anybody come across this issue before, and are there any solutions out there?

Thanks!

[Chris_F]

Bootcamp is just a tool to assist users in setting up a dual boot environment on their Mac. I find it very hard to believe that having used bootcamp to install Windows is going to have any effect on how the Windows API operates or what values it presents in the IParam. Why don't you start by posting the code.

[MrViggy]

Hello,

I am running Windows 7 on a Mac, using Apple's Bootcamp utility, such that the Windows installation is native. However, I am finding some issues when programming the Windows API using Visual Studio, specifically related to user inputs from the keyboard and mouse.

Suppose in a Windows program, the user presses a keyboard key. With a normal PC running Windows, in the WndProc() function, the message argument is WM_KEYDOWN and lParam is typically a number between 0 and 255, representing the key being pressed ("a", "s", "/" etc.). However, when debugging my program, I am finding that lParam is a very large number, eg. 847924401. I cannot find any obvious pattern in these numbers to map them over to the "standard" numbers expected in Windows. Similarly, when a mouse is clicked on the screen, the message is WM_LBUTTONDOWN and lParam indicates the cursor location, but this number is also a very large number, and not what is normally expected under Windows.

Has anybody come across this issue before, and are there any solutions out there?

Thanks!

No, lParam for a WM_KEYDOWN contains a lot more information then just a number between 0 and 255:

lParam

The repeat count, scan code, extended-key flag, context code, previous key-state flag, and transition-state flag, as shown following.
Bits Meaning
0-15 The repeat count for the current message. The value is the number of times the keystroke is autorepeated as a result of the user holding down the key. If the keystroke is held long enough, multiple messages are sent. However, the repeat count is not cumulative.
16-23 The scan code. The value depends on the OEM.
24 Indicates whether the key is an extended key, such as the right-hand ALT and CTRL keys that appear on an enhanced 101- or 102-key keyboard. The value is 1 if it is an extended key; otherwise, it is 0.
25-28 Reserved; do not use.
29 The context code. The value is always 0 for a WM_KEYDOWN message.
30 The previous key state. The value is 1 if the key is down before the message is sent, or it is zero if the key is up.
31 The transition state. The value is always 0 for a WM_KEYDOWN message.

Viggy

[VladimirF]

Has anybody come across this issue before, and are there any solutions out there?

MrViggy explained that this is NOT an issue.
A solution might be to process WM_CHAR message and look at its WPARAM.

[MrViggy]

A simple mask and shift would get the OP the data he/she wants.

Viggy