OLE Controls
Ed Kaltenbach -- kaltenba@ataway.aptec.com
Tuesday, January 09, 1996
Hello,
I am creating software that will display data in realtime. The users
will be able to "build" displays by selecting from several controls
and dropping them into a view. A data channel can be associated with
each control. The users will be able to change a few of the properties
like font but not all properties. The view can then be saved and reloaded.
This is similar to the way dialog windows are built in the Dialog editor.
This way the software stays generic and the users can build data display
views that are appropriate for his/her experiment.
The controls will be things like bar graphs, thermometers, scope plots,
voltmeters, etc. I will be writing these custom controls.
I am curious what are the benefits/tradeoffs of writing OLE Controls over
just deriving control classes from the CWnd class. All of the Common
Controls that came with MSVC++ 4.0 are derived from the CWnd class.
If I use OCX will I have to implement an OCX container?
If I subclass the Windows 95 CRichEditCtrl will I have to implement a
reflector window?
The FAQ says "...OCX controls have to implement a LARGE number of OLE2
interfaces, which makes the support code large...."
It also says "At present, OLE2 support in MFC happens in the "CCmdTarget"
class, which is the base class from which ALL "application architecture"
classes are derived. I guess the choice is to extend the OLE2 support in
this class to include OCX support (which would make ALL apps using OLE2
a LOT larger), or to add OCX-specific support to certain specific classes
such as CDialog. Either way, it's a major undertaking"
These statements imply that the coding is more difficult and the executable
will be larger if I use OCX.
Thanks,
Ed
---------------------------------------------------------------
Ed Kaltenbach Email: kaltenba@ataway.aptec.com
Applied Technology Associates Phone: (505) 767-1220
1900 Randolph Rd SE Fax: (505) 768-1379
Albuquerque, NM 87106
---------------------------------------------------------------
John & Annette Elsbree -- elsbree@msn.com
Saturday, January 13, 1996
> From: owner-mfc-l@netcom.com on behalf of Ed Kaltenbach
> If I use OCX will I have to implement an OCX container?
Yes, but MFC 4.0 has an implementation of OLE control containment built-in.
Look in the MFC Encyclopedia, under OLE Control Container. There are several
articles that explain how to use it.
> If I subclass the Windows 95 CRichEditCtrl will I have to implement a
> reflector window?
(Not sure quite how this question is related to the rest of the message.)
> The FAQ says "...OCX controls have to implement a LARGE number of OLE2
> interfaces, which makes the support code large...."
> It also says "At present, OLE2 support in MFC happens in the "CCmdTarget"
> class, which is the base class from which ALL "application architecture"
> classes are derived. I guess the choice is to extend the OLE2 support in
> this class to include OCX support (which would make ALL apps using OLE2
> a LOT larger), or to add OCX-specific support to certain specific classes
> such as CDialog. Either way, it's a major undertaking"
I must admit, I haven't read the FAQ lately (are you referring to Scot Wingo's
FAQ?). I'm not sure of the context for the sections you quote, but they sound
like they were written before MFC 4.0 shipped, and were speculation regarding
how MFC would/could be extended to support OLE control containment.
The fact is, MFC 4.0 implements OLE control containment in the CWnd class
(interesting: that's directly *between* CCmdTarget and CDialog in the
inheritance hierarchy). But no, it doesn't "make ALL apps using OLE2 a LOT
larger." In fact, for apps that don't use OLE controls, the only cost is a few
unused bytes in each CWnd instance.
> These statements imply that the coding is more difficult and the executable
> will be larger if I use OCX.
The coding (in an MFC-based container) is not more difficult. If you use the
DLL version of MFC, your executable probably won't be substantially larger.
However, your working-set will inevitably be larger, because you'll be using
more code from the DLL.
To decide whether to use OLE controls, ask yourself: will these controls
potentially ever be used in other containers? VB? Access? Web pages? If so,
you should consider OLE controls, since they are a cross-container solution.
If you're certain that your controls will be used only in MFC apps, don't
bother with OLE controls.
mfcTeam.m_johnels; // does not represent Microsoft
| Вернуться в корень Архива
|