Communicating Dialog Bar Combo Box Selections to Doc 
Author Message
 Communicating Dialog Bar Combo Box Selections to Doc

Got an MDI app with some ReBar bands containing combo boxes, whose selections I
want to communicate to my Doc.

By default the MainFrame manages the ReBar bands and can easily access their
embedded controls, so putting message handlers for dialog controls in the
MainFrame is easy.  The 'best' mechanism for communicating these selections
from the MainFrame to the doc(s) is less obvious to me, however.

OTOH, the doc(s) can only get to those controls via a route which appears to be
even more circuitous, so what's the recommended way to set this up?

--

Sr. Software Engineer, Visual Simulation Division, Autometric, Inc.



Mon, 20 Aug 2001 03:00:00 GMT  
 Communicating Dialog Bar Combo Box Selections to Doc
It should happen automatically. CRebar is derived from CControlBar.
CControlBar forwards all WM_COMMAND etc to its owner(parent). Look at
CControlBar::WindowProc() in BarCore.cpp.

--
Ajay Kalra


Quote:

>Got an MDI app with some ReBar bands containing combo boxes, whose
selections I
>want to communicate to my Doc.

>By default the MainFrame manages the ReBar bands and can easily access
their
>embedded controls, so putting message handlers for dialog controls in the
>MainFrame is easy.  The 'best' mechanism for communicating these selections
>from the MainFrame to the doc(s) is less obvious to me, however.

>OTOH, the doc(s) can only get to those controls via a route which appears
to be
>even more circuitous, so what's the recommended way to set this up?

>--

>Sr. Software Engineer, Visual Simulation Division, Autometric, Inc.




Mon, 20 Aug 2001 03:00:00 GMT  
 Communicating Dialog Bar Combo Box Selections to Doc

Quote:

> >Got an MDI app with some ReBar bands containing combo boxes, whose selections
> I
> >want to communicate to my Doc.

> >By default the MainFrame manages the ReBar bands and can easily access their
> >embedded controls, so putting message handlers for dialog controls in the
> >MainFrame is easy.  The 'best' mechanism for communicating these selections
> >from the MainFrame to the doc(s) is less obvious to me, however.

> >OTOH, the doc(s) can only get to those controls via a route which appears to
> be
> >even more circuitous, so what's the recommended way to set this up?

> It should happen automatically. CRebar is derived from CControlBar.
> CControlBar forwards all WM_COMMAND etc to its owner(parent). Look at
> CControlBar::WindowProc() in BarCore.cpp.

I'm not worried about the _msgs_ getting to the Doc.  Yes, I already know I can
put the msg handlers anywhere in the command routing path that seems "logical",
so I was putting a combo box handler in the Doc (and yes, a TRACE confirmed that
I was getting the combo box's SELENDOK msg just fine) when I realized that the
dialog bars object instances (and thus the combo boxes they contain) live in the
MainFrame, and the Doc doesn't include MainFrame.h by default (and vice versa),
so the Doc can't directly access a combo box's contents ....

IOW, my question wasn't really about the mechanics of the doc-view msg routing
architecture, it was a solicitation for opinions about the "best" strategy for
communicating between the MainFrame (which may have UI objects more
sophisticated than menu / toolbar buttons) and the Doc(s).  I've seen examples
where the authors just include the Doc.h file in MainFrame.cpp, so they can
directly access the Doc's properties and methods, ....

--

Sr. Software Engineer, Visual Simulation Division, Autometric, Inc.



Tue, 21 Aug 2001 03:00:00 GMT  
 Communicating Dialog Bar Combo Box Selections to Doc
I would not put Doc.h in MainFrame.h. It is much better to be otherway: Put
Mainframe.h in Doc. This would be the only way for an MDI app as there are
multiple document types.

The way I handle it is to provide access functions for the rebar and
combobox in MainFrame. Doc can therefore access it and populate it.

If you want to be really thorough(and this is what we do in our MDI app) is
to include rebars in doctemplate and create it after MainFrame is created.
This is very helpful when you have control bars which belong to a particular
document. There are other implications, like persistance of control bars if
you take this approach. But this makes it very scalable and indepent. This
make MainFrame a mere repository of control bars of various controlling
documents.

--
Ajay Kalra



Quote:

>> >Got an MDI app with some ReBar bands containing combo boxes, whose
selections
>> I
>> >want to communicate to my Doc.

>> >By default the MainFrame manages the ReBar bands and can easily access
their
>> >embedded controls, so putting message handlers for dialog controls in
the
>> >MainFrame is easy.  The 'best' mechanism for communicating these
selections
>> >from the MainFrame to the doc(s) is less obvious to me, however.

>> >OTOH, the doc(s) can only get to those controls via a route which
appears to
>> be
>> >even more circuitous, so what's the recommended way to set this up?


>> It should happen automatically. CRebar is derived from CControlBar.
>> CControlBar forwards all WM_COMMAND etc to its owner(parent). Look at
>> CControlBar::WindowProc() in BarCore.cpp.

>I'm not worried about the _msgs_ getting to the Doc.  Yes, I already know I
can
>put the msg handlers anywhere in the command routing path that seems
"logical",
>so I was putting a combo box handler in the Doc (and yes, a TRACE confirmed
that
>I was getting the combo box's SELENDOK msg just fine) when I realized that
the
>dialog bars object instances (and thus the combo boxes they contain) live
in the
>MainFrame, and the Doc doesn't include MainFrame.h by default (and vice
versa),
>so the Doc can't directly access a combo box's contents ....

>IOW, my question wasn't really about the mechanics of the doc-view msg
routing
>architecture, it was a solicitation for opinions about the "best" strategy
for
>communicating between the MainFrame (which may have UI objects more
>sophisticated than menu / toolbar buttons) and the Doc(s).  I've seen
examples
>where the authors just include the Doc.h file in MainFrame.cpp, so they can
>directly access the Doc's properties and methods, ....

>--

>Sr. Software Engineer, Visual Simulation Division, Autometric, Inc.




Tue, 21 Aug 2001 03:00:00 GMT  
 Communicating Dialog Bar Combo Box Selections to Doc
Alex:

The question you are really asking is: To what extent is it desirable to tie
yourself up in knots to be OOP correct when using doc-view?

A good question.

The current version of my app (SDI with a a split view) is very OOP incorrect -- I
think I have included all the headers in all the classes, for various wicked
purposes (but it was my first MFC profect, and my first real C++ project, and I was
sometimes desperate). I am determined to clean this up some in the next version, but
haven't really decided how.

If you look at an AppWizard created application (in SDI anyway) you will find that

1. The view knows about the document.
2. The application object knows about all the other classes.
3. The other classes know about the application object.
4. And that is all.

Most particularly, the document does not know about the view(s), and the views do
not know about each other. My app violates even this rule, and this I will certainly
fix.

Moving along, the above suggests that the application object should (or could) be
the clearing house for communication between the classes. But when I look at my
code, I find that I have written almost no code in the application object; in fact
the vast majority of my code, including most of the toolbar button handlers, are in
the document class. One thing I am certainly going to consider is moving a lot of
this code into the application object (some helper classes wouldn't hurt either).

Another striking feature of the AppWizard code is

5. Unlike the other classes, the frame class has a generic name.

Indeed, I do find that even my frame code does rather generic things, like saving
the window state in the registry, limiting the mimimum size of the window. It would
not be hard for me to rewrite my application so that the main frame class was
completely generic. So perhaps I will.

Just rambling here, really ...

David Wilkinson

================


Quote:

> > >Got an MDI app with some ReBar bands containing combo boxes, whose selections
> > I
> > >want to communicate to my Doc.

> > >By default the MainFrame manages the ReBar bands and can easily access their
> > >embedded controls, so putting message handlers for dialog controls in the
> > >MainFrame is easy.  The 'best' mechanism for communicating these selections
> > >from the MainFrame to the doc(s) is less obvious to me, however.

> > >OTOH, the doc(s) can only get to those controls via a route which appears to
> > be
> > >even more circuitous, so what's the recommended way to set this up?


> > It should happen automatically. CRebar is derived from CControlBar.
> > CControlBar forwards all WM_COMMAND etc to its owner(parent). Look at
> > CControlBar::WindowProc() in BarCore.cpp.

> I'm not worried about the _msgs_ getting to the Doc.  Yes, I already know I can
> put the msg handlers anywhere in the command routing path that seems "logical",
> so I was putting a combo box handler in the Doc (and yes, a TRACE confirmed that
> I was getting the combo box's SELENDOK msg just fine) when I realized that the
> dialog bars object instances (and thus the combo boxes they contain) live in the
> MainFrame, and the Doc doesn't include MainFrame.h by default (and vice versa),
> so the Doc can't directly access a combo box's contents ....

> IOW, my question wasn't really about the mechanics of the doc-view msg routing
> architecture, it was a solicitation for opinions about the "best" strategy for
> communicating between the MainFrame (which may have UI objects more
> sophisticated than menu / toolbar buttons) and the Doc(s).  I've seen examples
> where the authors just include the Doc.h file in MainFrame.cpp, so they can
> directly access the Doc's properties and methods, ....

> --

> Sr. Software Engineer, Visual Simulation Division, Autometric, Inc.




Wed, 22 Aug 2001 03:00:00 GMT  
 Communicating Dialog Bar Combo Box Selections to Doc

Quote:

> I would not put Doc.h in MainFrame.h. It is much better to be otherway: Put
> Mainframe.h in Doc. This would be the only way for an MDI app as there are
> multiple document types.

Agreed.

Quote:
> The way I handle it is to provide access functions for the rebar and
> combobox in MainFrame. Doc can therefore access it and populate it.

I may do that to populate the combo boxes, but since my first post I found (in
FAQ 6.4 of the _excellent_ MFC Answer Book) and successfully tested a nice
system for communicating control info from the MainFrame back to docs / views.
The MainFrame msg handler creates a WM_COMMAND with the combo box's ID in WPARAM
and a safe handle of the combo box in LPARAM.  The Doc msg handler pulls the ID
and handle out of the msg params and can then bang away at the combo box to its
heart's content.

Quote:
> If you want to be really thorough(and this is what we do in our MDI app) is
> to include rebars in doctemplate and create it after MainFrame is created.
> This is very helpful when you have control bars which belong to a particular
> document. ...

Thanks for the idea, I'll consider this approach.

--

Sr. Software Engineer, Visual Simulation Division, Autometric, Inc.



Fri, 24 Aug 2001 03:00:00 GMT  
 Communicating Dialog Bar Combo Box Selections to Doc
I have thought about this a bit when I need to have docs that update on a
timer.  I handle the timer in CMainFrame then use the global 'theApp' (yuck)
to iterate over all the docs, decide which ones are of the type I expect
(maybe STATIC_CAST or IsKindOf) then call a function in the doc in my case
Update()

Yes you need to include "MyDoc.h" in "MainFrame.cpp" this seemed ok to me.

Gordon




Quote:

>> >Got an MDI app with some ReBar bands containing combo boxes, whose
selections
>> I
>> >want to communicate to my Doc.

>> >By default the MainFrame manages the ReBar bands and can easily access
their
>> >embedded controls, so putting message handlers for dialog controls in
the
>> >MainFrame is easy.  The 'best' mechanism for communicating these
selections
>> >from the MainFrame to the doc(s) is less obvious to me, however.

>> >OTOH, the doc(s) can only get to those controls via a route which
appears to
>> be
>> >even more circuitous, so what's the recommended way to set this up?


>> It should happen automatically. CRebar is derived from CControlBar.
>> CControlBar forwards all WM_COMMAND etc to its owner(parent). Look at
>> CControlBar::WindowProc() in BarCore.cpp.

>I'm not worried about the _msgs_ getting to the Doc.  Yes, I already know I
can
>put the msg handlers anywhere in the command routing path that seems
"logical",
>so I was putting a combo box handler in the Doc (and yes, a TRACE confirmed
that
>I was getting the combo box's SELENDOK msg just fine) when I realized that
the
>dialog bars object instances (and thus the combo boxes they contain) live
in the
>MainFrame, and the Doc doesn't include MainFrame.h by default (and vice
versa),
>so the Doc can't directly access a combo box's contents ....

>IOW, my question wasn't really about the mechanics of the doc-view msg
routing
>architecture, it was a solicitation for opinions about the "best" strategy
for
>communicating between the MainFrame (which may have UI objects more
>sophisticated than menu / toolbar buttons) and the Doc(s).  I've seen
examples
>where the authors just include the Doc.h file in MainFrame.cpp, so they can
>directly access the Doc's properties and methods, ....

>--

>Sr. Software Engineer, Visual Simulation Division, Autometric, Inc.




Mon, 27 Aug 2001 03:00:00 GMT  
 
 [ 7 post ] 

 Relevant Pages 

1. Writing to combo box on dialog bar

2. Combo Box Selection

3. Combo Box selection change.

4. simple combo box w/ multiple selections

5. What message is sent after a combo box selection updates the member variable

6. How do I receive selection info from Combo Box in toolbar

7. Add Combo Box to Dialog Box

8. Add a combo box in a dialog box...

9. Combo Box in a tool bar... problems creating

10. communicate between dialog-boxes

11. Dialog bar, seperate doc/view thread not working with app's dynamic data

12. Combo box data in dialog editor

 

 
Powered by phpBB® Forum Software