https://bugs.documentfoundation.org/show_bug.cgi?id=49853
--- Comment #127 from Jan Holesovsky <[email protected]> --- Paul: I heard you were interested in looking into this, so let me add some more code pointers here... The actual task is to find out why pressing the Cmd-V does not hit the vcl::KeyCode::GetFunction() in vcl/source/window/keycod.cxx I'd try to put there a breakpoint, and see where is it called from when you press eg. the key 'a' (as according to comment 109, that case enters that), look up the stack, and see where it is coming from; you'll probably see something around vcl/osx/vclnsapp.mm or other .mm file. Then I'd try to put a breakpoint there in the .mm file, and see if you get at least there when pressing Cmd-V; and then find out what is different to the 'a' case, and try to fix that - so that you get to the GetFunction(). Talking about vcl/osx/vclnsapp.mm, I am particularly suspicious of the if( pKeyWin && [pKeyWin isKindOfClass: [SalFrameWindow class]] ) where in the 'else', they say // #i94601# a window not of vcl's making has the focus. // Since our menus do not invoke the usual commands // try to play nice with native windows like the file dialog // and emulate them // precondition: this ONLY works because CMD-V (paste), CMD-C (copy) and CMD-X (cut) are // NOT localized, that is the same in all locales. Should this be // different in any locale, this hack will fail. and continue with some stuff with cmd-c / cmd-v etc. So maybe as the first thing, I'd try to comment out the "&& [pKeyWin isKindOfClass: [SalFrameWindow class]]" part of the if, and if that helps, we know we need to find a way that still lets the native dialogs working, but makes the cmd-v in the toolbar work. -- You are receiving this mail because: You are the assignee for the bug.
_______________________________________________ Libreoffice-bugs mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
