Re: MFC and c++ problems



No, the interface is defined by the control. The parent follows the specification of the
interface to the control. Note that the messages of CButton are defined by the CButton
class (although implicitly in windows.h, in C++, if there were a class CButton : public
CWnd, then the values for WM_COMMAND, such as BN_CLICKED, would have been defined in the
subclass.)

The parenthetical remark also leads to an issue in design. In some cases, it makes sense
to just reuse WM_COMMAND with a function code to indicate what you want; then you can
easily add a notification by using ON_COMMAND(ctl, id, handler) to route it, or even

#define ON_WHATEVER(ctl, handler) ON_COMMAND(ctl, WN_WHATEVER, handler)

the problem is that it can't pass anything back. So then the other option is to define an
NMHDR-derived structure and use ON_NOTIFY, passing back whatever you want. I've used both
these techniques as well as custom messages, but much of what I do can be handled by
custom notifications.

Note the type safety issue is addressed in ActiveX by using the VARIANT structure,
although the recipient is expected to check the variant tag and not violate what it says.
joe

On Sat, 4 Feb 2006 17:10:56 -0800, "Tom Serface" <tserface@xxxxxxx> wrote:

Hi Doug,

I would think the parent would define which messages the child could send
and then the child would use those messages. Isn't this how most of the
controls on a dialog work?

Tom

"Doug Harrison [MVP]" <dsh@xxxxxxxx> wrote in message
news:9u0au197q2vbg2rk33ot0o7g16ko0pg7ad@xxxxxxxxxx

The thing about SendMessage is that it's not type-safe, and the target
window has to agree to interpret the number identified by WM_WHATEVER the
same way as the sender. Now, if it isn't a standard message, and the
target
window didn't define the message itself, and you didn't design the classes
to work together, then you have to use RegisterWindowMessage to negotiate
a
message you can both agree on. Using "interfaces" as suggested elsewhere
in
this thread solves these problems. A more general approach is exemplified
by the .NET event facility, in which objects interested in an event
register themselves with the object that generates the event; this is an
implementation of the Observer pattern. In C++, the primary (legitimate)
reason to use Windows messages instead of an OOP approach is to enable use
of the window from other languages. A secondary (not so legitimate) reason
is that it's quicker (and dirtier), especially when you're designing the
window classes together and can set up a common header file that defines
the message they'll both use.

--
Doug Harrison
Visual C++ MVP

Joseph M. Newcomer [MVP]
email: newcomer@xxxxxxxxxxxx
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
.