Printable View
Hello,
I'm writing a dialog based application. I have the main dialog and another dialog that opens up when I press a button (let's call that dialog1). On dialog1 I have a button. When I press this button, I want to do things to controls on the main dialog... for example display text on an edit box. How do I access an edit box (or other controls) on the main dialog from the other dialog?
Thank you.
I would make a pointer to the main dialog a member of dialog1. Set up member functions in the main dialog class that you can call when appropriate from dialog1.
I would send a user message to the parent dialog, and let it set the text to its own controls.
I'd choose the same way as VladimirF suggested. :cool:
What's the advantage to messages over direct function calls?
dialog1 does not need to (and should not) know anything about methods, member variables and any other things of a "main" dialog.Quote:
Originally Posted by GCDEF
It only should send/post some user defined message and then the main dialog should care about processing this message (if it would like to process it at all!)
I can appreciate the idea of loose coupling, but it also depends on whether dialog1 is modal or modeless.
It's going to need to know what custom messages to send. I'm not sure the difference is significant, and if dialog1's purpose is to control features of the main dialog, there's no inherent design problem with 1 knowing about main.Quote:
Originally Posted by VictorN
Of course if there is some sort of communication between these dialogs, there has to be a protocol.Quote:
Originally Posted by GCDEF
I am coming from the “need to know” principal: the secondary dialog doesn’t need to know about nature of main dialog controls.
All it should be concerned about is to notify its parent of some changes.
I also consider reusability: if there was justification to separate some controls into a secondary dialog, it might be used from some place else.
I would compromise on passing some interface pointer to the second dialog, but certainly NOT a pointer to the main one.
I never said the functions dialog1 calls needs to know anything about the controls. All it needs to do is let the main dialog know something and I don't see the advantage of messages over function calls.Quote:
Originally Posted by VladimirF
I think reuse may be a bit of a stretch here. Whether through function calls or messages, dialog1 will try to communicate with the main dialog somehow. How that communication is implemented doesn't change that behavior. I'm all for reuse but a lot of dialogs are for a pretty specific purpose.
Advantage is in the level of abstraction.Quote:
Originally Posted by GCDEF
Having a pointer to a main dialog as a member of child dialog violates my “need to know” principal.
That’s why I suggested exposing an interface that main dialog must implement.
Of course all of that depends on application. If we are lucky and OP will visit this thread, we might learn more about his design.
Jumping back into the fray here with my $.02...
As mentioned before, one of the main considerations is whether the child dialog is modal or modeless. If it is, then additional communication between the child and parent dialog is required and usually that takes the form of a user defined message. If it is a modal system, then I prefer to not use messaging to pass data.
Besides that point, I generally prefer to work in a doc/view model or at least the concept of a doc/view model. In other words, when the 'real' MFC generated doc/view model isn't available, I'll simulate one.
I typically take this approach to simple apps like dialog based or property sheet based applications. I'll create a 'doc' class that contains the data and get/set accessor methods to the data, then I pass a pointer to this class around to the main dialog and any child dialogs. I wire up the DDX controls of the dialogs to act on the accessors directly rather than having each dialog contain it's own variables that would need to be mapped to the 'doc' data.
To me this approach satisfies the 'need to know' principle. Although each dialog needs to know about the document, it doesn't need to know about any other dialog or the controls in any other dialog in order to set or get data.
In my MFC dialog-based app:
in dialog1 control handler:
CDialog1::OnBnClicked()
{
........
CMainDlg* mainDlgPtt = (CMainDLg*)GetOwner();
Call any main dlg function, get controls, etc.
...............................
}
If you have put the pointer to the main dlg as a parent in the constructor of CDialog1, you may send WM_PARENTNOTIFY messages to CMainDlg.
Note that you wouldn't need to know the type (class) of the "GetOwner" window if you decided to just Post/Send a user defined message to this GetOwner".
Once one needs to know, he is meant to be attracted, that example exhibits the polymorphic behavior of the dialogs. There is nothing in the encapsulation principle being violated as long as such casting works perfectly fine for him. But once he sees a message saying "you are banned from accessing this property, that function, methods etc", then something flares up to indicate the underlying hacks are being performed.Quote:
Originally Posted by VictorN