Is it to be expected that some key-down codes will vary depending on whether the widget set is GTK2 or Qt?
If it's expected, I can live with it. If it's not expected then I can give examples of where it's happening, with a UK keyboard over X.

Mailing lists / lazarus / 2012-04
4 messages · 3 people · –
Reply by email Subscribe to this list Your subscription
Read-only archive. Use j and k to move between messages.
Is it to be expected that some key-down codes will vary depending on whether the widget set is GTK2 or Qt?
If it's expected, I can live with it. If it's not expected then I can give examples of where it's happening, with a UK keyboard over X.
You mean OnKeyDown() sends different key codes for same stuff typed on keyboard ?
zeljko
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20120422/bf22dab4/attachment.html>
Is it to be expected that some key-down codes will vary depending on whether the widget…
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)
leledumbo wroteI 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.