Re: Ali R Can you guide me in this problem ??

From:

David Wilkinson <no-reply@effisols.com>

Newsgroups:

microsoft.public.vc.mfc

Date:

Mon, 15 May 2006 12:12:57 -0400

Message-ID:

<uGp0npDeGHA.1204@TK2MSFTNGP02.phx.gbl>

nicetom786@yahoo.com wrote:

Hi ,

First of all let me thank Ali,David and Eric for your efforts on this
issue .

I got the handle of second list controland now able to insert
successfully.

Since everyday is a part of learning ,I would like to ask these things
further and share with me?.

1.Why this is a bad design as I am delegating some of the work to take
care by itself rather than parent window?Is this not modularity ?

2.Am I not trying to keep the form view readable and there by handle
all control related messages in its own wndproc(MyListCtrl derived from
CListCtrl).

3.Handling of messages in a child window is Reflection . Will
Refelection make things worser ? What othe problems will this approach
face in future ?As I see only the handle to pass for manipulation?

Thanks to everybody,
Tom

Tom:

I agree with AliR that yours is not THAT bad of a design, but I would
not do it, even in his modified version.

Message reflection is not bad; in some situations it can be very good.
The classic example is CYellowEdit, an edit control that paints its
background color yellow. By reflecting WM_CTLCOLOR, you have a control
that you can use on any dialog, just by changing the type of the edit
control, without any need of handling WM_CTLCOLOR in the parent. THIS is
modularity.

By contrast, your (first) list control has functionality that can only
be used in the presence of another (sibling) list control. It violates
the principle that only the parent (or the child itself) should
manipulate the child. IMO, this is a more important criterion than
"keeping the view class readable." In fact, by keeping it "readable" you
have hidden from the next reader of the view code what the true
functionality is.

Take, for example, the MFC dialog paradigm:

void CMyDoc::OnSomeID()
{
   CSomeDialog dlg;
   dlg.m_var1 = m_var1;
   dlg.m_var2 = m_var2;
   if(dlg.DoModal() == IDOK)
   {
     m_var1 = dlg.m_var1;
     m_var2 = dlg.m_var2;
   }
}

This is lousy OOP (public variables), but its meaning is super-clear.
You do not even need to look at the dialog class to see what is does. In
fact, you may be able to write this dialog class entirely with the
ClassWizard (VC6-speak), without actually writing any code at all.

Sometimes clarity is more important than modularity.

David Wilkinson