|
|
|
OCX Controls vs. MFC Extension Libraries
Date: 11 June 96, 17:25 EDT From: Grant Rainford Email: exonsoft@mistral.co.ukRecently whilst looking around for a grid control, I was confronted with the question... OCX or MFC. After looking at a few zillion grid solutions, I prompted for Stingrays MFC Objective Grid. I eventually made the decision based on the feature list of the product, and in this case it happened to be a MFC extension library. Personally, if I can get the functionality I require from a MFC extension, then I would choose that in preference to an OCX solution.
Date: 12 June 96, 18:16 EDT From: Tim Craig Email: TimCraig@PE-Nelson.comThe major advantage of going to MFC extensions is that you can derive your own classes to enhance or modify behavior in the base class. Almost everyone has been in the situation where the canned solution wasn't "quite" what marketing wants for your product. If you can get source code, do it for three reasons. You need the source to intelligently derive new classes. If something isn't working as expected, you can debug into the extension if you have source code. If there are bugs, you're not at the mercy of the vendor to provide timely fixes or even remain in business.
Date: 12 June 96, 22:14 EDT From: Alan LazarusI haven't tried any MFC-based controls, but I've always wondered how professional they are. Sometimes I think that a company creating an OCX (oh, excuse me, ActiveX) control puts more effort into testing, since it *is* a black box, and that people who provide source-code solutions might be tempted to say "ah, heck, it works well enough, and anyway, if there's a bug, the user can fix it himself. Let's ship it." I have *no* proof to back this up -- I'm only saying that I wonder if this is the case.
Date: 14 June 96, 13:13 EDT From: Tim Craig Email: CraigTT@PE-Nelson.comI don't think you can make a banket statement that simply because you're given a "black box" the developer has exhaustively tested it. At least with source code you can judge the quality of the implementation and decide if using the code is safe and whether you'd buy additional componenets from the vendor in the future. An argument could be made that the code in the black box could have been slapped together in a very ugly fashion simply because no one will ever see it.
Date: 17 June 96, 9:16 EDT From: Darren Poulton Email: darrenp@taskey.comAfter using both add-ons (OCX and Class Libraries) I would have to say that I prefer the class library over OCX. Class libraries if well designed/written can easily be extended OCXs cannot. If an OCX does not do quite what you want, generally it is tuff luck. On the side of testing, I have found that class libraries provided by reputable companies (e.g Objective Grid from Stingray) are far more stable than OCX. I have been trying to find plug in components in the form of VBX (old days) and OCX but you can never find something that does exactly what you want.
Date: 18 June 96, 9:18 EDT From: Alan LazarusYou guys are starting to convince me that MFC-based tools are the way to go. Here's another factor in favor of them: portability. If you buy a package like Bristol's Unix MFC package, you can probably port all your MFC-based tools, since you have the source code.
Date: 19 June 96, 21:24 EDT From: Jacques Cooper Email: cooper@proton.llumc.eduI've tried using a few MFC extensions, and they were pretty bad. I think the developers of MFC extensions feel that since you have the source code, and if there's 1 or 2 or 3 or.. 1000 bugs, that you can fix them all yourself. However, I have neither the time nor the desire to fix someone else's code. On the other hand, I've used several OCX's and have had great success.
Date: 20 June 96, 11:41 EDT From: Grant Rainford Email: exonsoft@mistral.co.ukThe only MFC extensions I've used have been Stingrays and I've found them easy to use and very professional. Also the support is prompt and helpful. I would recommend anyone to try their extensions, which would help dispel the myth that source provided = lousy quality. (You can pay me later Scot
)
Date: 28 June 96, 23:08 EDT From: Sheldon Wosnick Email: sheldonw@mdr.comI feel that MFC extensions are the way to go for many of the reasons already discussed, namely: (1) possession of the code (I assume code is included) in case vendor goes bye bye; (2) ability to use inheritance to fine tune your derived classes (3) to evaluate for yourselves the quality of the code (no secrets in the black box); (4) for debugging purposes
Date: 28 June 96, 23:12 EDT From: Sheldon Wosnick Email: sheldonw@mdr.comI feel that MFC extensions are the way to go for many of the reasons already discussed, namely: (1) possession of the code (I assume code is included) in case vendor goes bye bye; (2) ability to use inheritance to fine tune your derived classes; (3) to evaluate for yourselves the quality of the code (no secrets in the black box); (4) for debugging purposes.
Date: 7 July 96, 9:59 EDT From: Charles Johnson Email: charlej9@telalink.netI use both a-x controls and mfc extensions...and I like them both. For solving relatively simple problems (put that .AVI in that window, give it to me one frame at a time with this pallette) an a-x control means I save time. On the other hand, a "treat the serial port as an i-stream, and put those stock-quotes here, with this format, and those symbols, at this rate"...well...access to source code is worth a lot. Which I guess is a long winded way to say "the right tool for the right job." Cheers-- Charles
Date: 7 July 96, 23:40 EDT From: Scot Wingo Email: scot@stingsoft.comOne problem with the whole 'black box' OCX/Ole control/what ever they're being called/ discussion is that OCX vendors only test one container - VB! The fact of the matter is that there are 10X more VB programmers than VC and OCX vendors focus on the VB market. That's why OCXs are so incredibly horrible in MFC applications both in terms of performance, bugs, functionality, etc.. With MFC extensions, the focus is on VC++/MFC compatibility so these aren't problems. Also, ever try to add a property or change the behavior of a 'black box'? It can be nerve racking.
Date: 8 July 96, 13:25 EDT From: Michael Zuniga Email: mzuniga@informix.comWell, one bad thing about MFC extensions is that they are usually tied to a specific version of MFC. So, say you have a really cool grid control written for MFC version 3.x and now version 4.x is out the door and isn't 100% compatible with version 3.x. How does that affect your control, and more importantly, any extensions you have written? What if the original vendor rewrites the MFC extension to take advantage of the newer version of MFC and that breaks your extensions? My preference is neither OCX nor MFC extension library, but a control written in C with an MFC wrapper and an OCX wrapper. With an OCX wrapped control, you are free of MFC changes between versions, and you can still subclass and manipulate the OCX control because it is a C control underneath.
Date: 22 August 96, 3:34 EDT From: Steve Rogers Email: steve.rogers@octel.comI think both OCXs and extensions have there place, it depends what you want to do. In general I would check OCX before extensions because; They are much easier to use. If you know some VB you can prototype the functionality you need very quickly to get a feel for the control and to show others your GUI before using it in your C++ application. There are more OCXs out there then extensions. I wouldn't have said this a year ago. I have changed my mind because I worked with VB 4.0 for a couple of months and it was quite an eye opener as regards using components for programming. I think Visual C++ engineers should try VB, for a while, just to see another way of doing things.
Date: 20 October 96, 21:31 EDT From: Jeff Armbruster Email: jeffrey.armbruster@internetMCI.comHow about the question of speed - performance? Extensions should behave faster than an OCX/ActiveX control. Has anyone heard of the hardware engineer's adage: "we do everything we can to make the hardware faster, while software developers do everything they can to slow it down."
Date: 25 October 96, 17:28 EDT From: Edinson Fernandez Becerra Email: edifer@armenia.uanarino.edu.coI need a control that able to open avi file and any other multimedia file
Date: 18 November 96, 19:57 EDT From: Todd Brannam Email: TBrannam@msn.comI've found the general quality of OCX's to be fairly low. It seems that OCX vendors don't treat them as Black Boxes... My biggest example is MicroHelp's OCXTools... After many calls and unresolved bug reports I was told that most hadn't been tested outside of Visual Basic. I liked the idea of OCX's code quality is code quality
Date: 24 November 96, 19:52 EDT From: Darren Poulton Email: darrenp@taskey.comI would take an MFC class library over an OCX anyday when it comes to anything more difficult than putting text on the screen. We have waisted big $$$$ not only in buying OCXes but in having people chase up non-existed support and incompatibilities with VC. On the topic of OCXes removing you from being VC version compatible, this is simply nonesense. We have time and again be thrown to the dogs because vendors do not test their products with anything but VB. You must pick you extension provider carefully, but and extension provider that knows the world of OO (which most OCX vendors do not) then they should be able to provide a well designed, robust product. After all, is this not one of the main reasons we are using C++.
Date: 24 November 96, 19:54 EDT From: Darren Poulton Email: darrenp@taskey.comThat last sentence was supposed to say. This is one of the main ....
Date: 20 December 96, 11:01 EDT From: Sanjay Gupta Email: sgupta@aegonusa.comI am looking for a grid control and data calcualtion libraries. We are using WinNT 4.0 and MSVC4.2. Any help will be greatily appreciated.
Date: 23 December 96, 21:02 EDT From: SDAFASDFSADF Email: SADFSDFASDSDFASDFASDFSADFSADFSDAFSDAFSAD
Date: 11 January 97, 2:03 EDT From: Tomer Siman-Tov Email: y_siman@netvision.net.ilI need any control that let me play wave filename in run-time. Olso, I need to change then wave volume & wave speed. If thers any EQ effects i`ll be very heppy to conect with you. Tomer
Date: 19 January 97, 14:06 EDT From: Jeffrey Armbruster Email: jeffrey.armbruster@internetMCI.comI've used OCXs, and MFC extension libraries, specifically Stingray and Dundas. OCXs always seem to come with a performance hit (slower than an extension). And OCXs always have canned behavior. Either you accept the behavior coded into the OCX, or you don't use it. Extension allow you to alter or enhance the library's behavior. And if an extension has a nasty bug, you can debug it yourself. Try debugging an OCX without the source code!
Date: 10 April 97, 23:28 EDT From: Dave Cunningham/DUNDAS Email: davec@dundas.comIf you program in VC++ there is really little benefit in using an ActiveX control. Sure, you can drop the control into a dialog and do some visual programming, but frankly, if we wanted this limited type of development environment we'd program in something else. Try dropping an ActiveX Control into an MDI app and see what kind of visual programming you can do! MFC Extensions like Ultimate Grid are totally native to MFC, provide you with high quality source code, and allow you to do *anything* you want. You're not stuck with the default behavior built into an ActiveX. Spend you time developing, not writing work-arounds. Just my two cents. (www.dundas.com)
If you just added a comment, and you don't see it, hit your "REFRESH" button.
This thread is for entertainment and educational purposes.
We reserve the right to delete any messages without notice.