is this settable in wxformbuilder as _base.cpp/h is autogenerated and can't be changed manually
On Wed, Jul 13, 2016 at 11:32 AM, Brano Panak <[email protected]> wrote: > i tried solution from wx forum, modified just for test > pcbnew/dimensions/grid file: > > dialog_set_grid_base.cpp > > m_sdbSizer1Cancel = new wxButton( this, wxID_CANCEL ); > with > > m_sdbSizer1Cancel = new wxButton( this, wxID_CANCEL , _T("Cancel")); > and look this works as supposed in my setup. > > could you test in on different platforms and if this is ok, i can apply it > elsewhere. > > regards > > Brano > > > > On 22/06/16 16:59, Wayne Stambaugh wrote: >> >> On 6/22/2016 10:33 AM, Collin Anderson wrote: >>> >>> I just discovered that OS X does in fact have similar behavior for >>> buttons. In most dialog windows, hitting command and the first letter of >>> the text will 'click' the button, but this only works when the letter >>> doesn't conflict with other shortcuts (like command-c or command-v for >>> example). >>> >>> To get around that, it just remaps close/cancel to command-period >>> (command-.) instead of command-C. >>> >>> Something weird is going on with how wxWidgets handles this. I think the >>> above behavior is done deep in the Cocoa API or something, and is not >>> something any program needs to specifically implement. I say this because >>> certain windows in KiCad actually have this correct behavior, even the first >>> letter activating the button. >>> >>> More troubling though is I just noticed that in windows where this >>> behavior is not working, other things are broken too. In OS X, you can use >>> tab and the arrow keys to highlight widgets like buttons, text fields, >>> whatever. Additional capabilities can be enabled in the accessibility >>> section of system preferences, and for many vision or motor impaired users, >>> this ability to highlight widgets is vital to them being able to use >>> software. For example, you can have text-to-speech enabled such that it >>> will read the text of a button currently highlighted. >>> >>> Anyway, this functionality is completely absent in any window where >>> button shortcut behavior is also broken. It is actually impossible to high >>> light or operate the GUI without a mouse in these windows. >>> >>> HOWEVER, all of that works flawlessly in the windows with the shortcuts >>> working. >>> >>> This seems completely separate from the command-c closing issue, and >>> adding or removing the "&" to the button string does not influence it. I >>> think its probably something to do with the window type. >>> >>> Examples of windows with correct behavior: >>> >>> Preferences in pcbnew >>> Most of the dimension dialogs in pcbnew >>> Color selection window for layers (you can also hit command-A and >>> it will click apply) >>> >>> Non-working windows: >>> Preferences in eeschema >>> most more complex windows (component library editor, paths >>> editor, netlist import/export, etc). >> >> I looked at some of the dialogs you've listed and they are all are >> derived from DIALOG_SHIM so it's not that. It may be worth looking at >> each dialog to see what events we are intercepting and whether or not >> that is the issue. The fact that some dialogs work properly and others >> do not makes me think that it could be an issue with our dialog design >> rather than an issue with wxWidgets. >> >>> >>> >>> >>> I suppose the 'proper' solution would be to disable wx's direct handling >>> of button shortcuts for OS X, while figuring out whatever it is that is >>> letting OS X perform native behavior in some windows or not others. >>> >>> >>> Sorry, this is all just observational stuff, I can't really be of much >>> help until or if I get a better handle on wx. >>> >>> That said, as an OS X user, I didn't even notice any of this until today, >>> and I've been using KiCad for a year+ now. So its hardly mission critical. >>> I also doubt there is anyone who is vision or motor impaired who is doing >>> EDA tasks with KiCad. >>> >>> Still odd though. >>> >> It may not be that odd. Some of this is due to wxGrid (and I suspect >> wxListCtlr and wxListView) behavior. wxGrid intercepts the usual return >> key behavior when you are editing a grid cell so the default button (OK) >> never receives the return key. This isn't that unusual. I've tested >> other non-wxWidgets applications with grids in dialog boxes and the >> behavior is similar. >> >> _______________________________________________ >> 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
