This is worse than web development. And that's saying something :) On Fri, Jan 8, 2016 at 11:16 AM, Chris Pavlina <[email protected]> wrote:
> Hi, > > Jesus, here be dragons. Finally got the hotkeys stuff working properly > on all platforms - this has been tested on Linux, Win10, and OSX. Thanks > to JP for a push in the right direction (and even that required more > work!). > > Quick summary of the problems: > > - On Windows, there is a bug/quirk somewhere, where if a Tab > keypress occurs in a dialog with nothing in the tab order, this > must NOT generate the corresponding wxEVT_CHAR. If this happens, > the entire application freezes solid. This has nothing to do with > wxTAB_TRAVERSAL, so disabling this style property does not help. > > - wxEVT_CHAR_HOOK can be used to catch this event early and block > the tab bug. It also has the benefit of catching other 'special' > keys that wxEVT_CHAR misses (again, on Windows. wxEVT_CHAR has no > problem receiving them on Linux). > > - .../however/, wxEVT_CHAR_HOOK reports some keys incorrectly. Any > shifted symbol keys are reported as shift+(the unshifted key), so > on a US keyboard for example, when you type <?>, it sees > <Shift>+</>. There's no easy way to map these to the "correct" > keys, particularly considering international keyboards. > > - When wxEvent::DoAllowNextEvent() is called (see below), > wxEvent::Skip MUST be called on Linux and OSX, and must NOT be > called on Windows. No... I don't know why. > > In the end, I implemented separate OnChar and OnCharHook handlers. > OnCharHook does the following: > > 1. If the keypress is a pure modifier (wxEVT_CHAR_HOOK generates > events for things like Ctrl by itself), do nothing. > > 2. If the keypress is for a printable character **that is not > whitespace** (to avoid tripping the Tab bug), call > wxEvent::DoAllowNextEvent to cause the wxEVT_CHAR for the same key > to be generated. Call or do not call wxEvent::Skip depending on > platform, as above. This causes the "correct" key to be looked up > (e.g. <?> instead of <Shift></>) and this progresses to the OnChar > handler. > > 3. For all other keys, do not allow the wxEVT_CHAR to be generated, > but instead pass the event object directly to OnChar. > > > Then OnChar handles returning the keycode to caller. > > Please, help me test this. Wayne, if this works, and you don't mind, I'd > really like to get it merged. Even if there are still minor GUI quirks > and whatnot, the current top of the devel branch has the hotkey bugs > from earlier that I'd like to get fixed. Any further minor issues can be > resolved in further minor commits. > > -- > Exasperatedly, > Chris > > _______________________________________________ > Mailing list: https://launchpad.net/~kicad-developers > Post to : [email protected] > Unsubscribe : https://launchpad.net/~kicad-developers > More help : https://help.launchpad.net/ListHelp > >
_______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : [email protected] Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
