Re: Re[2]: Mac shortcut keys issue. Keys being sent to parent frame window.

Igor Korot <[email protected]> Tue, 1 Apr 2025 10:04:46 -0500
Newsgroups gmane.comp.lib.wxwindows.general
Message-ID <CA+FnnTyJW4OQdjKexWT-8=TMFtuwqemq4HG7FgLjy1-1vpEkHg@mail.gmail.com>
Hi, Tony,



On Tue, Apr 1, 2025, 8:42 AM Tony Kennedy <[email protected]> wrote:

> ok, now I think I've got something that works. Previous attempt registered
> double key presses in certain controls.
>
> Two functions have been changed,  wxWidgetCocoaImpl::keyEvent in window.mm and -
> (void)sendEvent:(NSEvent *)anEvent in utils.mm (images below show the
> differences).
>
> In the existing wxWidgetCocoaImpl::keyEvent function (window.mm), when a
> key event happens, it's sent to the menu first. If I re-order the function
> to what is below (let the control have a go first), copy/paste work.
>
> Are there any Mac specialists here that can comment on this change?
>

Can you make a PR with your changes?

Thank you.


> Thanks in advance,
>
> Tony.
>
>
>
> --------------------------Replacement function sendEvent in
> utils.mm---------------------------------
> - (void)sendEvent:(NSEvent *)anEvent
> {
>     if ([anEvent type] == NSKeyUp && ([anEvent modifierFlags] &
> NSCommandKeyMask))
>         [[self keyWindow] sendEvent:anEvent];
>     else if ([anEvent type] == NSKeyDown && ([anEvent modifierFlags] &
> NSCommandKeyMask))
>         [[self keyWindow] sendEvent:anEvent];
>     else
>         [super sendEvent:anEvent];
> }
>
> --------------------------Replacement function wxWidgetCocoaImpl::keyEvent
> in window.mm---------------------------------
> void wxWidgetCocoaImpl::keyEvent(WX_NSEvent event, WXWidget slf, void
> *_cmd)
> {
>     wxLogTrace(TRACE_KEYS, "Got %s for %s",
>                wxDumpSelector((SEL)_cmd), wxDumpNSView(slf));
>
>     if ( !m_wxPeer->IsEnabled() )
>         return;
>
>     bool bTryPopagateToMenu = false;
>
>     if ( [event type] == NSKeyDown )
>     {
>         bTryPopagateToMenu = true;
>         BeginNativeKeyDownEvent(event);
>     }
>
>     bool bEventHandled = true;//false;
>     if ( GetFocusedViewInWindow([slf window]) != slf || m_hasEditor ||
> (bEventHandled = !DoHandleKeyEvent(event)) )
>     {
>         wxOSX_EventHandlerPtr superimpl = (wxOSX_EventHandlerPtr) [[slf
> superclass] instanceMethodForSelector:(SEL)_cmd];
>         superimpl(slf, (SEL)_cmd, event);
>     }
>
>     if ( [event type] == NSKeyDown )
>     {
>         EndNativeKeyDownEvent();
>     }
>
>     if  (bTryPopagateToMenu == true && bEventHandled == false)
>     {
>         if ( [[[NSApplication sharedApplication] mainMenu]
> performKeyEquivalent:event] )
>         {
>             wxLogTrace(TRACE_KEYS, "%s processed as key equivalent by the
> menu",
>                        wxDumpSelector((SEL)_cmd));
>             return;
>         }
>     }
> }
>
>
>
>
>
>
>
> On Tuesday, 1 April 2025 at 12:48:30 UTC+1 Tony Kennedy wrote:
>
>> Ahh, this doesn't quite work, so please ignore (for now).
>>
>> On Tuesday, 1 April 2025 at 12:32:39 UTC+1 Tony Kennedy wrote:
>>
>>> I've done a little experimentation on this today and seemed to have got
>>> something working. *But I'm really worried about any knock on effects.*
>>>
>>> Two functions have been changed,  wxWidgetCocoaImpl::keyEvent in
>>> window.mm and - (void)sendEvent:(NSEvent *)anEvent in utils.mm (images
>>> below show the differences).
>>>
>>> In the  wxWidgetCocoaImpl::keyEvent function (window.mm I think), for a
>>> key down event, it's sent to the menu first. If I re-order the function to
>>> what is below (let the control have a go first), copy/paste work.
>>>
>>> Are there any Mac specialists here that can comment on this change?
>>>
>>> Thanks in advance,
>>>
>>> Tony.
>>>
>>> On Wednesday, 26 March 2025 at 21:20:24 UTC Vadim Zeitlin wrote:
>>>
>>>> On Tue, 25 Mar 2025 09:52:10 -0700 (PDT) Tony Kennedy wrote:
>>>>
>>>> TK> No problem. I'm not familiar with objective C at all and not even
>>>> sure if
>>>> TK> the code below is objective C or Swift.
>>>>
>>>> It's Objective-C++ (as indicated by .mm extension, rather than the
>>>> standard .m for Objective-C), we don't use Swift.
>>>>
>>>> TK> I'm trying to trace things. In utils.m, I found the sendEvent
>>>> function. And
>>>> TK> in it, there is a test for NSKeyUp, and the Apple docs say that
>>>> it's
>>>> TK> depreciated. It also says there is an AppKit bug.
>>>> TK>
>>>> TK> https://developer.apple.com/documentation/appkit/nskeyup
>>>> TK>
>>>> TK> I tried replacing NSKeyUp with NSEvent.EventType.keyUp
>>>> TK> <
>>>> https://developer.apple.com/documentation/appkit/nsevent/eventtype/keyup>,
>>>>
>>>> TK> but it refuses to compile so I'm stuck.
>>>>
>>>> What was the intention behind this change? NSKeyUp is perfectly fine...
>>>>
>>>> Perhaps it would be worth removing this "if" (or even this entire
>>>> function) entirely -- maybe it's indeed why you get the events in a
>>>> wrong
>>>> window (although I'm not sure, as I'd expect the key window to be the
>>>> palette window).
>>>>
>>>> Regards,
>>>> VZ
>>>>
>>>> --
>>>> TT-Solutions: wxWidgets consultancy and technical support
>>>> https://www.tt-solutions.com/
>>>>
>>> --
> Please read https://www.wxwidgets.org/support/mlhowto.htm before posting.
> ---
> You received this message because you are subscribed to the Google Groups
> "wx-users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to [email protected].
> To view this discussion visit
> https://groups.google.com/d/msgid/wx-users/9c046e54-3652-4ae6-91d7-3ef3d5cb02bcn%40googlegroups.com
> <https://groups.google.com/d/msgid/wx-users/9c046e54-3652-4ae6-91d7-3ef3d5cb02bcn%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
>

-- 
Please read https://www.wxwidgets.org/support/mlhowto.htm before posting.
--- 
You received this message because you are subscribed to the Google Groups "wx-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].
To view this discussion visit https://groups.google.com/d/msgid/wx-users/CA%2BFnnTyJW4OQdjKexWT-8%3DTMFtuwqemq4HG7FgLjy1-1vpEkHg%40mail.gmail.com.