#10 Message Mapping Macros

[Anonymous]

Although Win32++ encapsulates the Windows API very well, developers are still stuck with the old way of handling messages and events
using the switch statements. This method seems good for small applications but for larger projects, excessive use of switch statements can lead
to a spaghetti code.

From my experience with other frameworks like OWLNext and WTL, handling of messages and events are much more neat through the use of
message mapping macros.

I wish that the future release of Win32++ would include message mapping macros making it suitable for large projects too and professional
developers have the option to use this new feature or use the traditional method using the switch statements.

[jianjun wang]

I think variable map is a big problem.

[Anonymous]

I don't think message mapping macros are big problems. By being familiar with the way how Windows handle messages as well as having the complete documentation for all the message mapping macros to use, everything would be a lot better.

As I have mentioned before, switch statements tend to become spaghetti code when there are too many messages and events you need to handle.

With this, message mapping macros would be very handy. Programmers who have backgrounds in ATL/WTL GUI classes would be very comfortable if there would be
message mapping macros for Win32++ which is an additional feature.

[David]

Thanks for your message.

I get two schools of thought on this sort of thing. Some people love macros for the message mapping, and some people hate macros for anything.

Just testing the waters here, but what is your reaction to something like this:

[code]
switch (uMsg)
{
case WM_LBUTTONDOWN: OnLButtonDown(lParam); break;
case WM_MOUSEMOVE: OnMouseMove(wParam, lParam); break;
case WM_LBUTTONUP: OnLButtonUp(lParam); break;
}
[/code]

Perhaps this provides us with the best of both worlds. No macro code substitution (just real C++), no spaghetti code, its tidy, and has maximum flexibility. What do you think?

Best regards,
David

[David]

To maplewang2011:

Why do you feel the variable map is a big problem? Its efficient and robust.

Regards,
David

[Anonymous]

Well, the switch statement you have posted is just a simple case. What if, there is a need to nest your code. For example, you want to handle events. This is done by overriding the OnCommand(WPARAM wParam , LPARAM lParam) function as shown below:

BOOL MyClass::OnCommand(WPARAM wParam , LPARAM lParam)
{
switch(LOWORD(wParam))
{
case IDC_LISTBOX1:
if(HIWORD(wParam) == LBN_DBLCLK)
return OnListBox1_DoubleClick();
case IDC_LISTBOX2:
if(HIWORD(wParam) == LBN_DBLCLK)
return OnListBox2_DoubleClick();
case IDC_LISTBOX3:
if(HIWORD(wParam) == LBN_DBLCLK)
return OnListBox3_DoubleClick();
case IDC_LISTBOX4:
if(HIWORD(wParam) == LBN_DBLCLK)
return OnListBox4_DoubleClick();
}

return FALSE;
}

Here, we are also interested in the notification code and you may notice that we still need to nest under each case statements.
While this code is good and efficient, it may not look neat anymore the moment we need to handle more events.

A much more complex situation can occur if we need to handle control notifications in a more detailed manner like
unpacking the informations we need in the wParam and lParam parameters which can even lead to a more nested switch
statements.

Programmers may also commit mistakes in using the switch statements such as forgetting to put the break statements after each case statements.

Things can be made much more neat by simply putting everything in a single line of statement using message mapping macros like these:

COMMAND_ID_NOTIFY_HANDLER(IDC_LISTBOX1 , LBN_DBLCLK , OnListBox1_DoubleClick)
COMMAND_ID_NOTIFY_HANDLER(IDC_LISTBOX2 , LBN_DBLCLK , OnListBox2_DoubleClick)
COMMAND_ID_NOTIFY_HANDLER(IDC_LISTBOX3 , LBN_DBLCLK , OnListBox3_DoubleClick)
COMMAND_ID_NOTIFY_HANDLER(IDC_LISTBOX4 , LBN_DBLCLK , OnListBox4_DoubleClick)

Now these lines of code are much more neat compared to the traditional switch statements shown above.
Also, these lines are also less prone to mistakes like forgetting the break statements in switch/case block.

If complete documentation is provided for these macros, many advanced and intermediate developers would easily learn the proper
use of these macro codes I have shown.

With these, I strongly suggest that the future release of Win32++ would include an additional feature to use message mapping macros
where advanced developers can simply include the necessary header files to enable this nice additional feature.

This would also make Win32++ suitable not only for complete beginners but also for advanced developers especially to those who
have backgrounds in ATL/WTL/MFC gui classes because message mapping macros are often very handy for large software projects.

[Anonymous]

In addition to my previous post, message mapping macros would save time and effort as there is less coding involved compared to using switch/case statements where more coding is necessary.

Therefore, message mapping macros can make things easier and faster.

[David]

I don't wish to take an I'm right, you're wrong approach here. I see this primarily as a debate over programming style. As such there is no real right or wrong, or even necessarily better or worse.

On the specific question on the OnCommand snippet you posted, I would probably handle that by message, rather than by message and control. Perhaps something like:

BOOL MyClass::OnCommand(WPARAM wParam , LPARAM lParam)
{
switch(HIWORD(wParam))
{
case LBN_DBLCLK: OnDoubleClick(LOWORD(wParam)); break;
}

return FALSE;
}

As I see it, there isn't be a need to nest anything within the switch statements, and for larger project we shouldn't.

Yes its true that switch statements can be error prone, but that is also true of much of C++. To suggest that switch statements need to be hidden behind macros because of this would be to suggest a flaw in C++ itself, at least to my way of thinking.

I can't help wondering which method Bjarne Stoustrup would prefer to see used. Without macros I suspect.

Best regards,
David

[Anonymous]

Although you have reduced the complexity in the OnCommand code you have posted, still, there is a need to do switch statements inside the function invoked which is OnDoubleClick(LOWORD(wParam)).

Again, the code you have posted will not save you from too much coding. Instead, more coding is now required using your approach although complexity seems to have been diminished. Therefore, the burden is still there
and it even got worst as more coding is now needed.

But with message mapping macros, less coding is needed and the more your code would be organized and last but not the least, minimal complexity is achieved. So, you can save more time and effort which is crucial
in large software projects.

With these advantages, I would still suggest an additional feature to use message mapping macros as these would make programmers life more easy.

When I say additional feature, it means that developers have the option to use it by simply including the required header file to enable such features. For those who still prefer to use the traditional switch/case
method, they also have the option not to use the additional feature.

Instead of letting the users reinvent their own wheel just to make things easier, why not provide them with tools that are ready to use?

Yes, there are developers who hate macros but still, there are some who loves it. So, why don't we try to be
in the middle? Who knows? We might be able to satisfy the needs of both groups.

[jianjun wang]

Hi, David:
I only want to it use less code on data exchange.

[Anonymous]

Hello David,

What are your plans on this? Have you read my last comment? I was wondering why you're not responding for so long. Four months have passed since I posted my last comment, but it seems like you're not responding.

Thanks,
Arnel

[Anonymous]

Sample Project demonstrating the use of message map macro

[Anonymous]

Hello David,

I just uploaded a zip archive TestDialog.zip containing the project that uses a message map macro defined in a header file msghandlers.h, you may want to check this file and if there's any error or anything that I've missed, please inform me or make the necessary corrections.

Hopefully, the documentations regarding the message mapping macros would be clear.

Please take some time to review the sample project especially the way how I've used the message map macros. You may notice that the developer can optionally (not mandatory) use the message map macros by simply including the header file msghandlers.h in the project.

I'm still hoping that this request of mine regarding the inclusion of message mapping macros in the future release of Win32++ would be approved by you.

Message map macros can help simplify coding instead of switch/case statements.

See the additional attachment for your reference. The application that I have created was tested with Borland C++ 5.5.

I just updated the message map macro and uploaded the updated example too.

You may notice that there were 2 attachments uploaded but each one have different timestamps and from these information, you can identify the latest one.

Thanks,
Arnel