Had to change the capture method for both reasons. The old wxListCtrl (IIRC) was the _only_ widget that captured them correctly.
I'm not completely a fan of the dialog either, but it's not all _that_ bad, and we're not the only ones doing it that way. At very least the XFCE settings dialog does that, as well as a few others I tested (that I don't remember right away). It's a pretty reliable way to make sure you're the only thing receiving an event. I'll look at the labels - they weren't truncated in my Windows builds, but maybe I changed something and didn't realize it. On Mon, Jan 11, 2016 at 02:11:36PM -0500, Wayne Stambaugh wrote: > Chris, > > I just finished testing this and I'm not sure about using a dialog to > capture the hotkey press. Did you have to do this to overcome using the > tabbed dialog or was it due to changing the control to a tree control? > If it's the tabbed dialog design, it might be worth leaving the hotkey > assignment dialog as a separate dialog. If not, I guess I can live > with it but it wasn't necessary with the previous hotkey dialog. One > other thing, you might want to avoid is using bold characters in the > hotkey capture dialog. They are getting truncated on my windows builds. > The longer the description, the worse the truncation. > > Cheers, > > Wayne > > On 1/8/2016 1:16 PM, Chris Pavlina 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 _______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : [email protected] Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
