Search Results

Search found 1 results on 1 pages for 'dasmonkeyman'.

Page 1/1 | 1 

  • WM_NOTIFY and superclass chaining issue in Win32

    - by DasMonkeyman
    For reference I'm using the window superclass method outlined in this article. The specific issue occurs if I want to handle WM_NOTIFY messages (i.e. for custom drawing) from the base control in the superclass I either need to reflect them back from the parent window or set my own window as the parent (passed inside CREATESTRUCT for WM_(NC)CREATE to the base class). This method works fine if I have a single superclass. If I superclass my superclass then I run into a problem. Now 3 WindowProcs are operating in the same HWND, and when I reflect WM_NOTIFY messages (or have them sent to myself from the parent trick above) they always go to the outermost (most derived) WindowProc. I have no way to tell if they're messages intended for the inner superclass (base messages are supposed to go to the first superclass) or messages intended for the outer superclass (messages from the inner superclass are intended for the outer superclass). These messages are indistinguishable because they all come from the same HWND with the same control ID. Is there any way to resolve this without creating a new window to encapsulate each level of inheritance? Sorry about the wall of text. It's a difficult concept to explain. Here's a diagram. single superclass: SuperA::WindowProc() - Base::WindowProc()---\ ^--------WM_NOTIFY(Base)--------/ superclass of a superclass: SuperB::WindowProc() - SuperA::WindowProc() - Base::WindowProc()---\ ^--------WM_NOTIFY(Base)--------+-----------------------/ ^--------WM_NOTIFY(A)-----------/ The WM_NOTIFY messages in the second case all come from the same HWND and control ID, so I cannot distinguish between the messages intended for SuperA (from Base) and messages intended for SuperB (from SuperA). Any ideas?

    Read the article

1