Re: MFC and c++ problems

Daniel James wrote:
In article news:<fa63u1pin4p62hk7umrn7bvrjvhlm3tk29@xxxxxxx>, Joseph M.
Newcomer wrote:
So a control subclass becomes a completely self-contained class in my
world.... It cannot look into any other class that might contain it,
including CWinApp, CView, or CDialog classes that might contain it.
GetParent()->SendMessage is the interface of choice, and this can
usually be concealed with some reasonable programming techniques.

I agree with most of what you wrote in that long post, joe, but I have to
play Devil's Advocate with you here for a moment ...

You say that a control must make no assumptions about its parent.

But, if a control sends a message to its parent, is it not making the
assumption that its parent can handle that message? How is this any better
than calling a method defined by the parent?

Think of it this way: Even though you know every possible message a
control can send, there are some that aren't handled, correct? I would
agree with Joe, and after I reviewed what I was doing (i was coding and
not designing..bad move), I realized that I could reuse this class as a
container in other classes. I will use the SendMessage() routine when
I'm done handling things (in this case, drag and drop), so that
whatever else is dependent on the goings on in the container class can
choose to handle these changes or not at that moment. I could see that
it would make sense to solve the problem I was having in two ways:
1. create a handler function in class A which handles the
SendMessage()'s from class B, so that (in this case) every time an item
is dragged and dropped, class A can update the other controls that are
contained in it.
2. Disregard all of the messages sent from class B, and when the (in
this case) dialog is closed or deconstructed, it can harvest the status
of the (in this case) tree control and update the backend data, which
is an INI file in this case.

I chose 1 because I was previously unfamiliar with this, and will now
use it when necessary :).

Semantically, of course, the parent is free not to handle any message that
it doesn't understand. Your program containing a control that sends
messages to its parent will compile and run ... but may not WORK, because
the control may require the parent to handle the messages it sends, and
make some response.

I can see where you're coming from, but there are ways to get around
this, right? I mean, how do you handle things in terminal programming
in C? scanf("%s",&cArray);, which waits for the user to input data.
I'm sure you could make some code work without handling all messages
sent.


I agree wholeheartedly with you that it is a great strength of OO
programming that there is no coupling between unrelated program components
.. but here we're dealing with components which do have some logical
(i.e. real-world) coupling. We can't hide from that, and we should be
prepared to allow it to be manifest in our expressions of the program.

I have considered making this a class in itself, where I can make
controls like it's a dialog, and there is a treectrl in it
already...but I don't know how much I will reuse this code yet, so
won't put in the effort. In this case, it would be coupled AND logical
:). But, I think Joe means that if one wanted to use the derived
CTreeCtrl class in a View rather than a dialog, it would be a lot
easier to reuse the code.

If MyControl calls methods in its parent directly there is a visible
connection between control and parent that documents the real-world
connection between their behaviours. If you place that control in a parent
that doesn't provide the methods that the control needs to call your
program will fail to compile ... which is rather better, in my book, than
having it compile and run but not work.

Yeah but the not work part is the fun part! That's what testing is
for, to get it to a point where it does work, and where the code
adheres to your coding standards, uses memory only it's designed to
use, and only handles those messages that it was designed to handle.

One could write an interface class that supported the method(s) needed by
the control, and make sure that any parent class using that control
inherited from the interface. One would pass the control's constructor a
pointer/reference to the parent *as an interface object* through which the
calls could be made ... that way the control does not need to know any
more about the parent class than is necessary, and the compiler can still
catch the error if an attempt is made to place the control in an
inappropriate parent.

You know, I am still wondering what you guys mean by this, because MFC
class wizard automatically passed a CWnd pointer to the constructor.
Do you guys mean not to pass a ClassA pointer (for instance) to the
constructor of ClassB?

But, again, what the hell do I know? I'm just a green kid out of
college with only Unix experience..meh.

-ben

.

Relevant Pages

  • Re: MFC and c++ problems
    ... You say that a control must make no assumptions about its parent. ... messages to its parent will compile and run ... ... One could write an interface class that supported the methodneeded by ...
    (microsoft.public.vc.mfc)
  • Re: Controls - Page_init order
    ... the control after the Page_Load. ... Parent that says "Inside the Parent Page_Load", ... e as EventArgs) Dim sTest as String trace.warn("Inside the ... execute first before anything else since it is initialization code. ...
    (microsoft.public.dotnet.framework.aspnet)
  • Re: MFC and c++ problems
    ... You say that a control must make no assumptions about its parent. ... messages to its parent will compile and run ... ... One could write an interface class that supported the methodneeded by ...
    (microsoft.public.vc.mfc)
  • RE: Master Detail Event Handling?
    ... > Your example hides the child records unless the user clicks the parent row. ... > then use to identify the child control to work with the child control events. ... >>> Parent Record ...
    (microsoft.public.dotnet.framework.aspnet.webcontrols)
  • Re: Getting components name from notification parameter?
    ... Parent or perhaps the Form they're on somehow, ... You can make the windowed control refer to the translation component ... inner component, it automatically goes away once the component has ... The Owner is passed from the TTranslator instance to the TWCMessage ...
    (alt.comp.lang.borland-delphi)