@Coises : My thoughts about the topics:
“IsDialogMessage” (“standard Windows way of separating messages that are directed to a non-modal dialog or any of its child controls from the normal flow through the message loop”)
and “WM_GETDLGCODE” (“If keyboard focus is in a control, that control will decide which keys it wants and which keys should be processed as container navigation”):
Basically the Lazarus component library (LCL) acts as a fully qualified message loop system that is able to react on nearly each message and notification within a windows message loop, nearly all WM_, eg. WM_KEY(down,press;up;…) can be detected and processed (*).
Normally it’s hard to detect any lacks here imo. However i initially looked into that hierarchy, as here, like everywhere else in the programming world, some business rules might have been come into play for to negate a message (like eg. an app can do when it nulls out an Enter Key for to suppress a beep; Key := #0).
(*) At least in the win32 “widgetset” as one within all those platforms: all-interfaces win32-interface
It depends a bit on whether someone compiles “cross-platform” or for an OS-specific build, ie. “win32”):
But - right, maybe that is it what matches your pointing! - there is no explicit call of “IsDialogMessage” itself within the LCL hierarchy (i grepped here)!
But it is a function that is known and predefined in the free pascal compiler system (FPC) though. And, so, there really low-level based apps can be written (and do exist) without the LCL, using basic TranslateMessage, DispatchMessage etc. which are calling “IsDialogMessage” explicitely.
“Matches your point” in so far as it makes understandable why without NPPM_MODELESSDIALOG (which calls “IsDialogMessage”) “most shortcut keys will be intercepted by Notepad++” - with other words, let NPP act as a gate-keeper for messages here.
In sum, with your explanations it’s much more understandable now for me what’s going on (hope so).
And why “RegisterForm” (-> the NPPM_MODELESSDIALOG-Send) in the docking formcreate now lets work again F2 (and Ctrl-c, Ctrl-v & co.) by the plugin. Otherwise the NPP gate-keeper would decide itself and won’t pass messages to the plugin that it claims for own usage, e.g as defined in the shortcut mapper.
I hope I’m somehow on the right track here :-)
I’d use this solution, it does indeed remove the issue :-)
(i have to sort out a few subsequent flaws now, but those are assumingly outside the current thread)
