I have observed this on Macs running both wxPython 4.x and the old Classic version.
If there are menu accelerators that use X, C or V corresponding to specific cut, copy or paste operations in an application that also contains one or more wx.TextCtrl fields, then when a TxtCtrl has the focus and, say, V is pressed with the intention of pasting some text into that field, then the action that is linked to the corresponding menu accelerator is performed instead. The same code running under Windows responds to V in the way I would expect, that is, the menu accelerator action is only performed outside of any TextCtrl. Is there any way to alter the Mac behaviour?
I don’t know details (and I could certainly be wrong about this) but my understanding is that this and things like it are due to a deeper integration between the native widgets and the overall Cocoa framework, and some assumptions on how things will be used that may be different than other platforms. In essence, the expectation is that the framework (cocoa) will handle the Edit menu operations rather than the widget itself handling it. Therefore, the accelerators are intercepted before the widget has a chance to get it. I don’t know if there is an easy way to avoid this.
···
On Tuesday, March 12, 2019 at 8:33:42 AM UTC-7, David Hughes wrote:
I have observed this on Macs running both wxPython 4.x and the old Classic version.
If there are menu accelerators that use X, C or V corresponding to specific cut, copy or paste operations in an application that also contains one or more wx.TextCtrl fields, then when a TxtCtrl has the focus and, say, V is pressed with the intention of pasting some text into that field, then the action that is linked to the corresponding menu accelerator is performed instead. The same code running under Windows responds to V in the way I would expect, that is, the menu accelerator action is only performed outside of any TextCtrl. Is there any way to alter the Mac behaviour?
I think you’re right, that certainly would explain the observed behaviour. The simplest workaround is to ask the user to right-click in the widget and to select (usually) Paste from the pop up menu that appears. I’m debating whether to change the accelarators from X, C or V to X, C or V using the RAWCTRL option to specify them but am a bit concerned that this could be confusing to the user if the accelerators are actually used;
···
On Wednesday, March 20, 2019 at 5:35:47 PM UTC, Robin Dunn wrote:
I don’t know details (and I could certainly be wrong about this) but my understanding is that this and things like it are due to a deeper integration between the native widgets and the overall Cocoa framework, and some assumptions on how things will be used that may be different than other platforms. In essence, the expectation is that the framework (cocoa) will handle the Edit menu operations rather than the widget itself handling it. Therefore, the accelerators are intercepted before the widget has a chance to get it. I don’t know if there is an easy way to avoid this.