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
| Вернуться в корень Архива |