Handler for ON_UPDATE_COMMAND_UI
Randy Sales -- rsc@halcyon.com
Monday, April 15, 1996
Environment: VC++ 4.0 and NT 3.51/4.0
I have been attempting to display line and column info in the status
bar of an MDI application using the ON_UPDATE_COMMAND_UI message
during idle time. I have finally succeeded, but not by following the
MSDN documentation. Three articles on the MSDN state that the
ON_UPDATE_COMMAND_UI handler for the status bar should be placed in
the CMainFrame class. (One of the three articles is Q99198, the
other two are almost identical in wording.) When I placed my handler
there, it was only called once during application start up and did
not work as expected then. Tracing the flow of other similar
handlers indicated they were being called during idle time as
expected, but mine was not. I finally got it be called as desired by
moving it to my view class and placing it in my view class message
map.
Does this have to do with the difference in message routing between
SDI and MDI applications? Why did I need to move my
ON_UPDATE_COMMAND_UI message further down in the hierarchry to get it
called? Was there a better way to handle this?
Thanks,
Randy Sales
--
RS Consulting
1521 1/2 Cedar Street
Everett, WA 98201
Phone 206-259-1056
Fax 206-259-1315
email rsc@halcyon.com
David W. Gillett -- DGILLETT@expertedge.com
Wednesday, April 17, 1996
[Mini-digest: 2 responses]
> Environment: VC++ 4.0 and NT 3.51/4.0
>
> I have been attempting to display line and column info in the
> status bar of an MDI application using the ON_UPDATE_COMMAND_UI
> message during idle time. I have finally succeeded, but not by
> following the MSDN documentation. Three articles on the MSDN
> state that the ON_UPDATE_COMMAND_UI handler for the status bar
> should be placed in the CMainFrame class. (One of the three
> articles is Q99198, the other two are almost identical in
> wording.) When I placed my handler there, it was only called once
> during application start up and did not work as expected then.
> Tracing the flow of other similar handlers indicated they were
> being called during idle time as expected, but mine was not. I
> finally got it be called as desired by moving it to my view class
> and placing it in my view class message map.
>
> Does this have to do with the difference in message routing
> between SDI and MDI applications? Why did I need to move my
> ON_UPDATE_COMMAND_UI message further down in the hierarchry to get
> it called? Was there a better way to handle this?
I believe you've hit the nail precisely on the head. If you look,
for instance, at the resources generated by AppWizard for an MDI app,
you'll see TWO menu resources -- one for the frame when no view is
open, and one for the default type of view. I infer that when a view
is open in an MDI app, its menu applies and not the default
IDR_MAINFRAME menu. So each view class should have its own set of
ON_UPDATE_COMMAND_UI handlers, and handlers in the main frame class
are not expected to be called much.
Dave
-----From: jlandry@infosense.com (Jason Landry)
Are you returning the value returned from the parent class?
This is in the derived CWinApp subclass, OnIdle function.
My code looks like this:
BOOL CCidApp::OnIdle(LONG lCount)
{
BOOL retval=CWinApp::OnIdle(lCount);
...do my own processing
...if I have more processing to do, set retval to TRUE;
return retval
}
If you return .f. and don't call the parent class, none of the
framework's update commands get done.
If you don't return false at some point (in other words, return
the value returned by CWinApp::OnIdle(lCount) ) your application
will use WAY to much processor time (run the system monitor
and have it always return TRUE and you'll always be near 100%).
Hope this helps.
Jason Landry
Randy Sales -- rsc@halcyon.com
Monday, April 22, 1996
[Mini-digest: 3 responses]
Larry Siden wrote:
>
> I am a bit confused by one point. When you write "I
> > > finally got it be called as desired by moving it to my view class
> > > and placing it in my view class message map.", do you mean that
> you made the view become the owner of the control bar instead of the
> frame? Because the control bar's CControlBar::WindowProc() re-routes
> all its WM_COMMAND type messages to its owner unless you override it
> to reroute them somewhere else.
No, if I understand what you are saying, I did not make the view become
the owner of the status bar. I added a string ID to the indicators[]
array in my CMainFrame class and placed the handler for it in my CView
derived class's message map (using an ON_UPDATE_COMMAND_UI mapping) instead
of placing it in my CMainFrame class's message map, as I would have expected
to. I then made the associated handler a part of my CView derived class.
>
> I have a similar issue with a full OLE server. An OLE server has two
> frame window classes, the main (standalone) frame, and an in-place
> frame class. I designed a dialog bar that should appear in both
> cases. The dialog controls need to be serviced by handlers.
> Normally, these handlers should go in the frame window's message map,
> because MFC treats control-bar type windows and adornments as if they
> are merely additional controls belonging to the frame window.
> However, in a full OLE server with two frame classes, this means that
> the handlers for dialog bar controls would need to be duplicated. I
> handled this by overriding the control bar's CWnd::WindowProc() (as I
> mentioned above) so that the dialog bar can handle its own control
> notifications and control update messages, but I must still wonder if
> there is not a better way to handle this.
>
> Has anyone else had this issue when writing a full OLE server with two
> frame window classes? What other strategies are available to help one
> avoid having to provide redundant message handlers for frame controls
> and adornments that are common to both the main frame and in-place
> frame windows?
>
> > Date: Wed, 17 Apr 96 16:14:54
> > From: "David W. Gillett"
> > Cc: mfc-l@netcom.com
> > Sender: owner-mfc-l@netcom.com
> > Precedence: list
> > Reply-To: mfc-l@netcom.com
> > Content-Type: text
> > Content-Length: 2432
> >
> > [Mini-digest: 2 responses]
> >
> > > Environment: VC++ 4.0 and NT 3.51/4.0
> > >
> > > I have been attempting to display line and column info in the
> > > status bar of an MDI application using the ON_UPDATE_COMMAND_UI
> > > message during idle time. I have finally succeeded, but not by
> > > following the MSDN documentation. Three articles on the MSDN
> > > state that the ON_UPDATE_COMMAND_UI handler for the status bar
> > > should be placed in the CMainFrame class. (One of the three
> > > articles is Q99198, the other two are almost identical in
> > > wording.) When I placed my handler there, it was only called once
> > > during application start up and did not work as expected then.
> > > Tracing the flow of other similar handlers indicated they were
> > > being called during idle time as expected, but mine was not. I
> > > finally got it be called as desired by moving it to my view class
> > > and placing it in my view class message map.
> > >
> > > Does this have to do with the difference in message routing
> > > between SDI and MDI applications? Why did I need to move my
> > > ON_UPDATE_COMMAND_UI message further down in the hierarchry to get
> > > it called? Was there a better way to handle this?
> >
> > I believe you've hit the nail precisely on the head. If you look,
> > for instance, at the resources generated by AppWizard for an MDI app,
> > you'll see TWO menu resources -- one for the frame when no view is
> > open, and one for the default type of view. I infer that when a view
> > is open in an MDI app, its menu applies and not the default
> > IDR_MAINFRAME menu. So each view class should have its own set of
> > ON_UPDATE_COMMAND_UI handlers, and handlers in the main frame class
> > are not expected to be called much.
> >
> > Dave
> >
> >
> > -----From: jlandry@infosense.com (Jason Landry)
> >
> > Are you returning the value returned from the parent class?
> > This is in the derived CWinApp subclass, OnIdle function.
> > My code looks like this:
> >
> > BOOL CCidApp::OnIdle(LONG lCount)
> > {
> > BOOL retval=CWinApp::OnIdle(lCount);
> > ...do my own processing
> > ...if I have more processing to do, set retval to TRUE;
> > return retval
> > }
> >
> > If you return .f. and don't call the parent class, none of the
> > framework's update commands get done.
> >
> > If you don't return false at some point (in other words, return
> > the value returned by CWinApp::OnIdle(lCount) ) your application
> > will use WAY to much processor time (run the system monitor
> > and have it always return TRUE and you'll always be near 100%).
> >
> > Hope this helps.
> >
> > Jason Landry
> >
> >
--
RS Consulting
1521 1/2 Cedar Street
Everett, WA 98201
Phone 206-259-1056
Fax 206-259-1315
email rsc@halcyon.com
-----From: lsiden@jade.bioimage.com (Larry Siden)
I am a bit confused by one point. When you write "I
> > finally got it be called as desired by moving it to my view class
> > and placing it in my view class message map.", do you mean that
you made the view become the owner of the control bar instead of the
frame? Because the control bar's CControlBar::WindowProc() re-routes
all its WM_COMMAND type messages to its owner unless you override it
to reroute them somewhere else.
I have a similar issue with a full OLE server. An OLE server has two
frame window classes, the main (standalone) frame, and an in-place
frame class. I designed a dialog bar that should appear in both
cases. The dialog controls need to be serviced by handlers.
Normally, these handlers should go in the frame window's message map,
because MFC treats control-bar type windows and adornments as if they
are merely additional controls belonging to the frame window.
However, in a full OLE server with two frame classes, this means that
the handlers for dialog bar controls would need to be duplicated. I
handled this by overriding the control bar's CWnd::WindowProc() (as I
mentioned above) so that the dialog bar can handle its own control
notifications and control update messages, but I must still wonder if
there is not a better way to handle this.
Has anyone else had this issue when writing a full OLE server with two
frame window classes? What other strategies are available to help one
avoid having to provide redundant message handlers for frame controls
and adornments that are common to both the main frame and in-place
frame windows?
-----From: lsiden@jade.bioimage.com (Larry Siden)
I guess one crucial fact that I forgot is that even though a
WM_COMMAND message is received by the frame, MFC still routes it thru
the view's message map, then the frame, then the doc, then the app.
So anyone can get a shot at it until it is handled.
The confusion was purely my own.
-larry
| Вернуться в корень Архива
|