Re: Exchanging the string data between two dailogs
On Nov 30, 4:45 pm, Joseph M. Newcomer <newco...@flounder.com> wrote:
****
SetDlgItemText belongs in the junkbin of history, along with GetDlgItem. =
It is simple:
there is a variable called c_EditFirst which is bound to the control, the=
n write
c_EditFirst.SetWindowtext(s);
If you are writing more than one GetDlgItem per year, you are not using M=
FC correctly. If
you are writing more than one SetDlgItemText per century, ditto.
****
Joe, I knew you'll disagree, and I don't care (I say this without
disrespect). I am not a fan of control member variables, and when I
found it expedient to have a dialog without them, I do it. IOW, in my
book, occasional use of GetDlgItem, Get/SetDlgItemText do not hurt.
This is extremely bad. The second dialog should not even know of the e=
xistence of the
first dialog, let alone know there are methods in it! And given this is a=
modal dialog of
the first, the first does not have to display the string as soon as it ch=
anges; instead,
it should wait until the second dialog finishes and then extract the stri=
ng from a CString
variable
I agree with this last part, but I was going by "when i enter the data
int the text box, same data has to be reflect on its Parent Dailog" of
the question.
NO dialog should ever know of variables or methods which are not part of =
it. Importing
methods from other dialogs ranks high on the poor-modular-design list.
In the worst case, if you really need immediate response, the correct sol=
ution is to put a
CWnd * pointer in the child dialog, and use SendMessage to notify it.
Yes, I agree that second dialog should not know about the first, or
it's methods, for exactly the reason you evoke, modularity. However, I
disagree with the use of SendMessage. Yes, that can be done, but
that's way to loosely coupled for what it does, and it has a lot of
presumptions. I mean, when you read
"m_RandomWnd.SendMessage(WM_SOME_TEXT_CHANGED,
reinterpret_cast<WPARAM>(&someString)).
Here's IMO better design:
sharedInterface.h
class ITextChangeNotification
{
virtual void OnTextChanged(const CString&) = 0;
};
first.h
class CFirst : public CDialog, private ITextChangeNotification
{
virtual void OnTextChanged(const CString&);
};
second.h
class CSecond : public CDialog
{
CSecond(ITextChangeNotification& Listener) : m_Listener(Listener) {}
ITextChangeNotification m_Listener;
};
In other words, a specific interface is better than SendMessage.
Send message is bad for following reasons: it requires a CWnd. That's
incidental coupling (my interface can be used without CWnd). It
requires a dedicated WM_ message where none is actually required. It
requires giving up type safety (reinterpret_cast) to be able to go
through SendMessage. It even doesn't lower code complexity compared to
a separate interface.
I know that people are using SendMessage in the way you describe and
that majority will find explicit interface above odd and complicated.
Well, what can I say? They are wrong for sticking to the old
SendMessage idea (familiarity is a strong force). That idea comes from
the old C days, where it could have been interesting. Not so today.
Goran.