On 1/11/2016 2:16 PM, Chris Pavlina wrote: > Had to change the capture method for both reasons. The old wxListCtrl > (IIRC) was the _only_ widget that captured them correctly.
Maybe that's why the person who design the original hotkey dialog end up using wxListCtrl. It's certainly something to consider. I know it doesn't layout as nice as the tree control. > > 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. Thanks. > > 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 > _______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : [email protected] Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
