OnShowToolbars
Fredrik Gunne -- fgunne@agema.se
Thursday, September 26, 1996
Environment: NT4.0, VC++4.1
I'm developing an OCX which will be used as an embeddable object in =
Excel.
Like most objects, my OCX needs some UI objects (menus and toolbars).
For menus, it's simple: override COleControl::OnGetInPlaceMenu( ), which =
is called by the framework when the control is UI activated, and return =
an HMENU.
For toolbars, it's another matter. There is a =
COleControl::OnShowToolbars, but all the documentation says is: "Called =
by the framework when the control has been UI activated".=20
I have read "Inside OLE" (well, not all of it...), and it's pretty clear =
what I'm supposed to do: negotiate for some space in the container's =
frame etc.=20
But what if I want dockable and floating toolbars? What is the MFC way =
of implementing OnShowToolBars? To use CToolBar, I need a CFrameWnd =
which I don't have because my OCX certainly does not adopt to the =
doc-view model. I've searched MSDN and the Web, without finding one =
example of how OnShowToolbar could be implemented.
Any ideas?
Fredrik Gunne
AGEMA Infrared Systems AB
=20
Mike Blaszczak -- mikeblas@nwlink.com
Saturday, September 28, 1996
At 09:32 9/26/96 +0200, Fredrik Gunne wrote:
>Environment: NT4.0, VC++4.1
>I'm developing an OCX which will be used as an embeddable object in Excel.
>Like most objects, my OCX needs some UI objects (menus and toolbars).
It's hard for me to understand why you're writing an OLE Control, then, and
not a normal OLE object. OLE controls fire events, and Excel can't hear
them. Both OLE objects and OLE Controls can have properties and methods,
and Excel macros can party on both. Why don't you use a building block
that seems more appropriate? Is there some reason you haven't exposed to us
that would explain why an OLE control is more appropriate for you?
.B ekiM
http://www.nwlink.com/~mikeblas/
Don't look at my hands: look at my _shoulders_!
These words are my own. I do not speak on behalf of Microsoft.
Fredrik Gunne -- fgunne@agema.se
Monday, September 30, 1996
The reason that I'm making an OLE control and not an OLE object
is that the OLE control will not only be used as an embeddable
object. I also intend to develop several applications using the control.
I think that one of the good things with OLE controls is that, to the
"normal" user, the object appears to be an ordinary OLE object.
For the developer, the control is a powerful tool for developing new
applications. Having to make both an OLE Control and an OLE object
would be a waste of time.
I am aware that this is a rather unusual solution. The MFC support for
inplace menus and toolbars only exists for OLE objects (i.e. local servers
and not OLE controls). However, I am not going to let that stop me (not yet
anyway).
Now, to return to my original question:
How should I implement COleControl::OnShowToolbars to get dockable toolbars
in an OLE control?
----------
From: Mike Blaszczak
Sent: Sunday, September 29, 1996 5:04 AM
To: mfc-l@netcom.com
Subject: Re: OnShowToolbars
At 09:32 9/26/96 +0200, Fredrik Gunne wrote:
>Environment: NT4.0, VC++4.1
>I'm developing an OCX which will be used as an embeddable object in Excel.
>Like most objects, my OCX needs some UI objects (menus and toolbars).
It's hard for me to understand why you're writing an OLE Control, then, and
not a normal OLE object. OLE controls fire events, and Excel can't hear
them. Both OLE objects and OLE Controls can have properties and methods,
and Excel macros can party on both. Why don't you use a building block
that seems more appropriate? Is there some reason you haven't exposed to us
that would explain why an OLE control is more appropriate for you?
.B ekiM
http://www.nwlink.com/~mikeblas/
Don't look at my hands: look at my _shoulders_!
These words are my own. I do not speak on behalf of Microsoft.
| Вернуться в корень Архива
|