How could I create similar structure to handle Win32 Messages like it is in MFC?
In MFC;
BEGIN_MESSAGE_MAP(CSkinCtrlTestDlg, CDialog)
//{{AFX_MSG_MAP(CSkinCtrlTestDlg)
ON_BN_CLICKED(IDC_BROWSE, OnBrowse)
ON_BN_CLICKED(IDC_DEFAULTSKIN, OnChangeSkin)
ON_WM_DRAWITEM()
ON_WM_MEASUREITEM()
ON_WM_COMPAREITEM()
ON_BN_CLICKED(IDC_CHECK3, OnCheck3)
//}}AFX_MSG_MAP
END_MESSAGE_MAP()
BEGIN_MESSAGE_MAP macro handles this behaviour. What to do for pure Win32?
The MFC message map doesn't use a regular WndProc per se. IIRC, it is based on some kind of hook mechanism.
However, I guess it shouldn't be very hard to adapt the macros to an usual WndProc.
The 1st approach that comes to mind is to let the macros create an array of Message id/Handler function pairs. Even better: Use a map for improved performance.
Your WndProc would loop through that array to identify the given
WM
and execute the corresponding handler.You might also want the
BEGIN_MESSAGE_MAP
macros to mimic aswitch
statement where eachON_BLAH()
line would be acase
line inside the switch().That should be too hard.
You could use something like a std::map< short, MessageFn >. Where short is the window message and MessageFn is the function that handles the message. You can then handle messages as follows:
It won't be quite as neat but would be pretty easy to implement, though you'd be defining the message map at runtime rather than at compile time.
Another solution is to read through the MFC macro code and see how microsoft did it ...
Another solution, if you want MFC like behaviour without the overhead, is using ATL. You can also have a look at ATL's macro definitions to see how they did it ....
Edit: You can solve WM_COMMAND or WM_NOTIFY handling by storing a CommandMap and a NotifyMap as well. You then set the WM_COMMAND handler to a function that then does a similar thing and passes the command on through the CommandMap.
Your biggest issue is the fact that you don't get anything in the message that identifies a specific class instance. This isn't a problem if you only need the hWnd but youj may need to store a further global map of HWNDs to class instances ...
This is only 1 solution. You can solve the problem in many different ways. I'm just throwing 1 idea out there for you.
Here is a breif summary of the code I use to do this in the Zeus programmer's editor:
Step 1: Define a couple of message structure to hold the Windows message details:
Step 2: Define a base window class with a few special methods:
Step 3: Define a few macros to do the dispatching of the Windows messages:
Step 4: Define the dispatcher method:
Step 5: Define the static window procedure method (NOTE: this method will need to be used as the Window procedure of the window class when the class is first registered):
Now, using this base class it is possible to define a new window class that will look like this:
Edit: How this code works.
The secret to understanding how this code works is to remember the wndProc in the xWindow class is nothing but a Win32 Window procedure passed to RegisterClassEx when the Win32 Window is registered.
Now if you look at the wndProc code you will see it does a bit of setting up and checking but generally it does nothing more than send the Windows message to the dispatch method.
The dispatch method is even simpler as it does nothing more than pack the Windows message into an easy to move structure and then sends it off to the dispatchToMsgMap method.
Now look at the MyWindow class an you will see this code:
This code is just using the macros defined earlier. If you take a close look at these macros you will see the code above is in fact creating a dispatchToMsgMap method. This is the exact same dispatchToMsgMap method that was called by the dispatch method.
I know this method of handling Windows messages does work as I use this exact same approach in the Zeus for Windows editor.
It's difficult to do this with something like an
std::map
. In particular, that requires that every item in the map has the same type, but different messages have handlers that take different numbers of parameters, so pointers to them aren't the same type.You might want to take a look at the message cracker macros (especially
HANDLE_MSG
) in windowsx.h though. Though this really just generates case's for a switch statement, it still lets you write code that looks something like an MFC message map.