How to maintain consistency with MFC-Macros

9 views
Skip to first unread message

Pelle

unread,
May 14, 2010, 6:12:26 AM5/14/10
to

Dear all,

I have ever so often shot myself in the foot with MFC macros like
BEGIN_MESSAGE_MAP
IMPLEMENT_DYNCREATE

and more. The point is that all of these macros take your class and
parent-class as parameters.
If during development your class hierarchy changes and you forget to
update those macros, things can go wrong in just about any way. Some
cruel and some very subtle.
Now, what I am about is the subtle errors that arise when changing
things like your class hierarchy, because the errors that arise might
be hard to notice and even harder to find (it has already taken me
days to track down this type of issues several times)

This said there should be a way to maintain consistency with these
macros some way. I know the best way would probably be to put away
with MFC altogether since it is seriously aging and there are better
tools around these days, but for those of us still busy with legacy-
applications life would be seriously easier with any help on this
topic.
I'd be curious if anyone has found a way to deal with this consistency-
problem.

Thanks in advance,
Pelle.

John H.

unread,
May 24, 2010, 12:28:29 PM5/24/10
to
Pelle wrote:
> MFC macros like
> BEGIN_MESSAGE_MAP
> IMPLEMENT_DYNCREATE
> The point is that all of these macros take your class and
> parent-class as parameters.
> If during development your class hierarchy changes ...

> I'd be curious if anyone has found a way to deal with this consistency-
> problem.

I mostly use the Find in Files functions to look for the instances of
classes and variables when changing, but you're correct that making
changes to the code created initially by the wizards is problematic.
I haven't run into it too often and I try really hard to figure out
the "name" for my projects before getting too deep into them so as not
ot have to make wholesale name changes.

I've also found that the compiler finds a lot of these problems for me
and, although the messages are sometimes vague, I usually know about
what I changed so about where to look for the problem. The macros are
often expanded into many lines of unseen code so that is even more
mysterious.

I've found that hovering over the macros with Intellisense helps
sometimes since you can see the expansion. Also, right clicking on
them and selecting "Go to Definition" is helpful since you can see
immediately where they are defined in the MFC code.

That doesn't give you the "filled in" version very easily and I agree
this is a confusing way to implement.

I think MFC is still very appropriate for many projects. Being "old"
doesn't make it bad :o)

Tom

John H.

unread,
May 24, 2010, 12:30:35 PM5/24/10
to
Pelle wrote:
> I have ever so often shot myself in the foot with MFC macros like
> BEGIN_MESSAGE_MAP
> IMPLEMENT_DYNCREATE
> and more. The point is that all of these macros take your class and
> parent-class as parameters.
> If during development your class hierarchy changes and you forget to
> update those macros, things can go wrong in just about any way. Some
> cruel and some very subtle.
> Now, what I am about is the subtle errors that arise when changing
> things like your class hierarchy

Well, if you can be very disciplined about it, you could do something
like this:

class Base {
typedef Base thisClass;
};

class Derived : public Base {
typedef Derived thisClass;
typedef Base baseClass;
};

You would then use thisClass and baseClass consistently in MFC macros.
Now the problem is reduced to not forgetting to update the typedefs
whenever you change class hierarchy. Maybe it'll prove easier -
there's only one place per class that needs to be updated, and it's
right there at the top of the class declaration.
--
Igor Tandetnik

Reply all
Reply to author
Forward
0 new messages