Re: Help with default class object name.
Daz wrote:
David Wilkinson wrote:
Daz:
It is not, IMO, good OOP design, but from anywhere in an MFC dialog
application you could do
CMyDialog* pDlg = (CMyDialog*)AfxGetMainWnd();
CString str = pDlg->ReturnPath();
David Wilkinson
It seems to work beautifully, I will have a long study of it to see if
I can work out what's going on. I guess it's just a cast from CWnd to a
CDocFinderDlg pointer.
I understand that it may be bad practice, (although it's definitely
convenient), but would would the ideal way be?
Thanks for the reply, it's nice to finally feel that I understand the
very thing I am trying to achieve, not just how to achieve it.
Daz:
The most important thing is that you understand why it works, and are
comfortable with communication between objects.
But the reason this design is not so good is that it will only work if
your MyListBox object is part of an MFC dialog-based application in
which the main dialog is of class CDocFinderDlg, which has a method
named ReturnPath(). If you changed to, say, an SDI application with the
view derived from CFormView, it would no longer work.
I am assuming that your MyListView is a child of your CDocFinderDlg.
Generally, it is OK for the parent to know about the internals of the
child, but not the other way around. Normally, controls send messages
(notifications) to the parent, and the parent takes action. While
handling the user action in the control (using message reflection, I
assume) appears to be better OOP, often it is not because the child does
not have all the information it needs, and has to "reach out" to its
parent to get it (as you have discovered).
David Wilkinson