leledumbo wrote:
I don't really know about it, but as long as you use VK_* constants from LCLType unit I guess it would be no problem (well... I never had such a problem on GTK2 / Qt / WinAPI, the 3 widgetsets that I use)
But in the current case I want to know what key is pressed, not what character is coming through, and none of the VKs is widget-set specific. Let me give an example: on a UK keyboard, there is a key to the left of the Z which has \ and | On GTK2, irrespective of whether shift is pressed, this appears as 0xdc; on Qt this appears as 0xdc unshifted and 0x7c shifted- obviously the shift state is also available so I can work out what's actually pressed.
In the case of all 36 alphanumeric keys both GTK2 and Qt agree, i.e. both a and A appear as 0x41 so I presume this is the conventional behaviour. Same applies to cursor keys. Some of the dozen or so locale-specific keys behave in the same way, while (at least on a UK keyboard) some have different codes depending on whether they're shifted or unshifted.
I've not seen any indication that the system I'm using is misconfigured, it's running KDE so I presume all the apps take Qt's behaviour in their stride. It might be that Debian is at fault here and that there's some minor misconfiguration of Qt, but if it affects me it will affect others. I've not been able to test with a US keyboard, I've hunted around but don't have one.
I've coded round the problem with minimal inconvenience and limited cussing, but I'd appreciate confirmation that this is something that "just happens" rather than an issue I should be raising as a bug.
-- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] -- _______________________________________________ Lazarus mailing list [email protected] http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
