Thanks for the reply.
Even though, my post was not in that direction, and since you brought it up I will try to clarify this issue.
>>Chris: It's weird because Scintilla sends notification messages to it's owner window instead of its own hWnd.
I do not know what you are expecting here, that is rather weird! You want a control to send a notification message
to itself? what for?
>>Chris: It's undocumented but it is consistent and I haven't found any other method that allows handling wm_notify message through its own WndProc.
Again, I do not know what you are expecting. When you start using WndProc, you are no longer doing .NET but Win32 and in Win32 this is a
well documented process - reflected messages.
In fact, in ATL (and hence WTL) you will find at least 12 message macros related to this alone: FORWARD_NOTIFICATIONS, REFLECT_NOTIFICATIONS,
DEFAULT_REFLECTION_HANDLER, REFLECTED_COMMAND_HANDLER etc.
These reflected messages are prefixed OCM_, instead of the normal WM_, and for the notification message it is OCM_NOTIFY in olectrl.h file.
#define OCM_NOTIFY OCM__BASE + WM_NOTIFY
#define OCM__BASE WM_USER + 0x1c00
and in the winuser.h file you will find the
#define WM_USER 0x0400
Compute the value of the OCM__BASE and you will see where the 0x2000 value is coming from.
Now, back to the original post. I do not know how well to put this, but trace the codes in the WndProc and you will see that the handling of the Scintilla
notifications is not "enclosed" in any if statement, which is typically checking that "undocumented" state you talked about.
NOTE: On the reflected messages, since the reflected messages can originate from all child window/control (like list box in auto-complete popup),
you will typically check if the handle is that one you are looking for before processing the messages as such.