Caution:OLE 2.0 AheadEverybody reading this magazine should support OLE 2.0. Some day. The question is not whether.ItÆs when. And for many corporate and commercial programmers, that means a slow, cautiousapproach. The Microsoft evangelists donÆt always give enough airtime to OLEÆs pitfalls. IÆvenoticed four key problems.1. OLE DOESNÆT WORK YET. Try creating a complex compound document on an 8 MB386 machine. Object linking and embedding is painfully slow and cumbersome on the typicalcorporate desktop computer. Even worse, when users open three or four big applications at once,they experience delays and crashes. Now try mailing around that compound document. BecauseOLE 2.0Æs link tracking is weak, the links probably break and the document has little value.Jesse BerstIt gets worse. Windows has no standard document formats. If you create a compound documentusing six different applications, everyone who receives that document must own the same sixapplicationsùthey probably need the exact same versions. Without those exact same applications,users canÆt view or print the linked and embedded objects. If you want to distribute thesedocuments to your clients and suppliers, they, too, must own all six applications. So donÆt thinkthat end users will flock to your product just because it has OLE 2.0 support. Some day, OLE 2.0will be a mandatory feature. But not until it works better.2. OLE IS STILL TOO HARD TO PROGRAM. Not only does OLE 2.0 introduce 400new API calls, it also forces programmers to follow a different programming model. If you haveGUESTan older app you may need to tear it down and start all over again to make OLE 2.0 work.Part of the difficulty comes from the way Microsoft has pulled the rug out from under earlyadopters. Due to ôbug fixes,ö the company has changed the spec several times, to the detriment ofcompanies that supported the preliminary specs. Still, most of the trouble has nothing to do withMicrosoft. Switching to a new programming model literally takes years. OLE 2.0 forces you tomake that switch.This problem will improve in time. IÆm convinced that Microsoft will introduce OLE 2.0 aidsfor its programming tools. In the meantime, donÆt think that OLE 2.0 is something you can add inthe course of a week or two. ItÆs a fundamental shift in the way you program. As such, it requiresIMPLEMENT OLE 2.0a major, long-term commitment.3. OLE HAS COMPETITION. When Microsoft created OLE 2.0, the company chose toAND OLEignore IBMÆs System Object Model and the standards proposed by the Object Management Group,an industry consortium. Although I consider it unlikely, it is possible that OLE 2.0 could getsidetracked by rival specifications that adhere to open standards. The biggest competition willAUTOMATIONprobably come from the OpenDoc specification now in the works from WordPerfect Corp., AppleComputer Inc., and IBM. Personally, IÆm betting on OLE 2.0, despite its problems.The OpenDoc committee has promised to support OLE 2.0, so an investment in OLE 2.0AT YOUR OWN PACE,compatibility would not be wasted, even if OpenDoc ultimately becomes the preferred standard.However, you could also find yourself forced to switch from OLE 2.0 to a different object model.ItÆs a risk you should be aware of.NOT MICROSOFTÆS.4. THERE IS NO SUPPORT STRUCTURE FOR OLE. Microsoft likes to talk about theday when youÆll be able to buy OLE 2.0 components and plug them together to create customsystems. Microsoft ignores the fact that thereÆs no way to sell or support such applications. Someday, this stumbling block may be overcome by companies that act like systems integrators. Theywill collect, customize, and assemble components into custom solutions. These foundries mayeven pay developers on a royalty basis, following the model of the record business. Or perhapsweÆll see mainstream suite vendors distributing catalogs of compatible OLE components.Electronic and CD-ROM distribution will keep down the costs.Right now, itÆs best to think of OLE 2.0 as a better model for building your software. Over time,you should re-architect your software along object-oriented lines. Over time, you should useMicrosoftÆs component object model to modularize your software and reduce your developmentcosts. Over time, you should take advantage of the new tools and testing mechanisms becomingavailable to make OLE 2.0 support much, much simpler.Yes, you should move toward full OLE 2.0 compatibility. But do it at your pace, notJesse Berst is Editor and PublisherMicrosoftÆs. For most of you, that means a cautious, step-by-step approach. nof the Windows Watcher newsletter. Contacthim at 15127 NE 24th St.,Suite 344, Redmond, Washington 98052;via MCI Mail: JBERST; orCompuServe at: 71337,2052.112 FEBRUARY/MARCH 1994 Visual Basic ProgrammerÆs Journal
(.txt)