@Ylvy said:
I didn't understand this ll thing, based on these two examples i gave (wParam of wheel and lParam of KeyEvent) is it still possible to it construct wrong messages at sometime or is it correct now?
LPARAM is a typedef for __int64, which is Microsoft's extension type name for 64bit signed integers (same as int64_t in modern C++), so when dealing with constants for it you should be using signed 64bit integers, for example 1LL. As @JonB said it stands for long long int, which is the old way of standard C++ to mean "at least 64 bit" (it is always 64 bit on 64bit Windows).
WPARAM is a typedef for unsigned __int64, so when dealing with it you should be using unsigned 64bit integers, for example 1uLL, which stands for unsigned long long int.
The type of (1<<31) expression is int, since all operands are int and that is a 32bit signed integer on Windows. When using it in expression like lParam | (1 << 31) it gets upcasted to 64bit type, because the left operand is a signed 64bit value. (1<<31) is a negative 32bit signed value, so when upcasted to 64bit you get 11111... at the extended part of the 64bit value (C++ uses Two's complement binary representation), which caused your problem. A type of (1LL << 31) expression is long long, since the left operand is a long long constant. It already is a 64bit value with 00000.... on the first 32 bits, so there's no upcasing needed when you | it with lParam.
Btw. keep in mind that what I said is about 64bit Windows. If you target 32bit Windows too then LPARAM and WPARAM are typedefs for 32bit types long and unsigned int, so use 32bit constants there.
A side question, why Qt use a different value for the key modifiers Qt::ControlModifier, etc, than Microsoft?
Why should it be the same as Microsoft? Qt is a cross-platform framework with roots in Linux. I don't see any reason why it should use the same values for private implementation as any particular vendor, not just Microsoft.
