什么是ActiveX

什么是ActiveX

什么是ActiveX
这里讲得是你发现的对ActiveX所作的最简单的定义。ActiveX是OCX 的高级形式（也许把它看作OLE的较简单形式更合适）。但是，这个简单定义不能表达ActiveX控件的实质，用户认为ActiveX 就是 OLE 。对程序员来说，ActiveX 还是一套用于Internet的实能技术。它提供了过去没有的一种信息交换方法。
注释 Microsoft 目前正在开发一种新的Internet专用的组件技术，称为COM 。尽管许多内部网使用了ActiveX，而且ActiveX依然将用作应用程序组件，但ActiveX从未在Internet上广泛被采用过。ActiveX 在Internet上失败的理由有三条：组件大小，安全考虑以及缺乏对非Microsoft浏览器的兼容性。请谨记，你或许应该考虑把ActiveX控件作为公司内部使用的解决方案，而不是做为Internet的实现技术。
作为真正欣赏ActiveX的程序员，就不得不从程序员的角度去看一下OLE，这就是意味着要看一下OCX。从用户的角度看，OCX所做的都是在两个应用程序（或操作系统与一个应用程序）之间交换数据。OCX比数据交换的内涵要丰富得多。它们包括着一种称之为组件对象模型(COM)的概念。COM是定义对象模块间标准二进制接口的规范。这个接口定义了函数调用方法、基于标准结构的数据传送技术以及几个标准的函数调用。使用COM 意味着，你写应用程序模块（如OCX）时使用何种语言都无关紧要，因为模块接口在二进制层次上是相同的。
注释 写作本书时，Microsoft正在设计WebView，它是Internet Explorer与Windows 95系统的Explorer之间的一种集成技术。这一新技术使得对Web 站点的访问就像对Explorer中列出的驱动器或其它资源的访问一样容易。还可以看到你比较熟悉的 URL已被普通英文名称所代替。你可以在Windows 98中看到这一技术的实际运用。
COM怎样对你写的应用程序产生影响呢?答案是相当复杂的，原因在于使用COM的方式众多，倒不是因为技术本身是多么复杂。当用户把一个图形图像对象放入你的应用程序控制的容器中时，你对这个对象知道些什么呢? 实际上你只知道是谁首先创建了它。知道这一信息就允许你在这个应用程序中调用许多服务，这些服务包括显示这个图形或允许用户编辑它。实际中，你在做的是共享应用程序的代码。
程序员也能从使用COM中受益。当把一个OCX安装到你的程序设计环境中时，实际上你完成了什么呢?大多数情况下，你拥有了一个粘贴于窗体某处的一个新控件。你不必真正地知道控件的内部工作原理，唯一重要的因素是，控件能为你的应用程序做些什么，以及如何与它打交道。你可以使用标准接口来调用安装到你机器中的特定代码模块，这就是COM。
ActiveX是这种思想的扩充，仍然使用标准接口，但是，不再简单地从本地机器环境或LA/WA网的常设连接上调用代码，而是从Internet调用它。另外，这一新的代码能采用applets（包含内容的小程序）或微小应用程序的形式。
ActiveX将为你做些什么
OCX能为桌面系统做些什么，ActiveX就能为Internet做同样的事。但是，你将在以前从没想到的地方发现ActiveX控件。例如，etManage,Inc公司计划创建一个新的客户机，称之为Z-Mail Pro。这一软件包支持ActiveX技术的方式是，允许用户直接地在消息查看窗口中交换、创建以及查看HTML文档。这就意味着用户拥有了创建动态Web 页的能力，这种能力正是你今天不得不实际完成的任务。
远程连接也会从ActiveX的使用中受益。例如，Proginet Corporation 目前正在开发把主机(Mainframe)数据带到桌面系统去的ActveX技术。它的Fusion FTMS（文件传输管理系统）可以使用支持 OLE 容器的任何开发语言，比如Delphi，Visual C以及PowerBuilder。从本质上看，你将把一个ActiveX控件放入一个窗体，定义到哪里去数据，然后依靠控件进行连接。Internet上的远程访问不再要求用户去钻过马戏团中的大铁圈了（即不用在连接中跳来跳去了）。主机上一个特殊的传输服务器通过自动化地处理所有传输请求而完成打包。操作员在客户能访问公司站点之前再也不用人工地为站点下载一个必需的文件了。
甚至于Microsoft Exchange也会从ActiveX受益。Wang Laboratories,Inc. 和其它公司正在创建将Exchange和ActiveX混合在一起的新的附件。Wang的产品是客户机/服务器图像附件，它允许用户扫描、查看、注释、操作或打印图形图像， 而不用考虑这些图像位于何处。正是这个产品，还包括了一个层次存贮管理的ActiveX控件。将这两种技术组合在一起，使得在大公司中使用和访问图形变得容易了。它们还使得寻一个所需的图形变得容易了，这最终导致公司节约了存贮空间。
Microsoft自己也发布了许许多多的ActiveX控件。其中有些可以从Microsoft的Internet站点( http://www. microsoft. com) 免费下载，这些新的控件有用于PowerPoint 的Animation Player以及用于Access和Schedule的InternetAssistant（Internet助手）。Access的Internet助手能为要上载的数据库表格拍出快照作为静态图像，每当用户访问该页时，快照都会自动更新。Schedule 的Internet助手允许把日程表信息加载到Web页，因为每当用户访问站点时都会自动更新这些数据，所以再也不用担心在家上班的雇员会缺席会议了。最后，PowerPoint 的动画放映机则允许你在任何兼容ActiveX的浏览器中演示PowetPoint的演示文稿。
最后，如果认为ActiveX无助于安全性，那还要再推敲一下。这些日子里，许多的新的防火墙和证书策略正在轮番出现，其中一个是et2000 。et2000 是由许多API 构成的，允许开发人员把etWare内核服务（包括目录、 安全和特许证书）放入自己的应用程序中。你可以在内部网中通过ActiveX控件来选择这个API。这种做法对用户和开发人员有什么帮助呢? 这意味着，在适当的程序设计结构下，网络管理员能够追踪整个网络中的特许使用，这种追踪甚至于跨越Internet连接。当更多的人开始在家中而不是在办公室中进行计算工作时，这就变成了一个非常重要的课题。
ActiveX与OCX控件
就绝大多数情况来说，ActiveX控件和 OCX 控件是完全可以互换的。可以看到与Internet风马牛不相及的ActiveX控件广告，仔细一看，就会发现，在不久以前，这些控件大概还出现在OCX控件列表中。当然，你要仔细观察这些控件。即使ActiveX控件与OCX 控件确实共享了同一继承，ActiveX控件与OCX控件也不完全是一回事。请记住，ActiveX 控件是能够在Internet上工作的。
Internet对程序设计环境带来了一些特殊的挑战。你不再能够奢求高速装入，OCX 在因特网环境中使用时，其规模成了一个严重的问题，下载一个60KB的OCX 就对用户的耐心带来了考验，而试图下载一个200KB的OCX 大概会导致用户中断下载。而ActiveX 控件是OCX的小型版本。
注 OCX和ActiveX控件的一个主要差别是ActiveX控件通常要小一些（轻一些）。
ActiveX控件也在受到各种机器专用需求的牵制。在机器上安装OCX时，安装程序能对机器进行检测并作出所需的许可。对ActiveX控件却不能这样要求。在这里你不能对客户机作任何假定，客户机可以是新的奔腾，也许是昨日的8086。（如果你的ActiveX控件确存在某种平台限制，那么，要么设法解决它，要么肯定每个使用它的人都清楚这一限制。）
你还需要应付OCX程序员从未想到的情况。比如，如果浏览器根本不支持ActiveX时会发生什么?目前处理这一问题的方法是，浏览器对那些不知作如何处理的HTML 标记只是简单地忽略掉。在这种情况下很容易应付一个与ActiveX不兼容的浏览器——只需打出一条消息，让用户知道他们的浏览器不能在当前页工作并指导用户换一个浏览器就可以了。
基于MFC与基于ATL的控件
Visual C为了说明它比其它程序设计语言有完善的开发环境，它包容了两种创建ActiveX控件的方法：MFC和ATL（Active模板库）。但是，这一灵活性也带来了其它开发人员没遇到的一些问题。比如，怎样确定创建哪一种类型的控件? 一些开发人员通过在他创建的所有控件中使用同一种技术来解决这个问题，但这样做本身就表明，你还没有真正地钻研并利用Visual C的全部潜力。
注 用Visual C创建ActiveX控件有两种方法：ATL和MFC。
确实没有任何理由能肯定地说，在给定的情况下，创建控件使用哪种方法会更好。真正需要做的是弄清楚：你期待控件做些什么，你打算对什么进行开发从而获得所需功能，以及你的专业知识水平。显然，有些情况下，创建控件用这种方法比另一种方法更好，因为，两种方法确实各有利弊。当把一个ATLActiveX控件与一个MFC ActiveX控件作对比时，需要考虑一些因素，为了给你一些对这个问题的基本看法，请读完下面列出的各条注意事项，从这里会发现一些对你有用的基本思路，从而帮助你选择一种最好的方案。
开发速度 使用MFC ActiveX Control Wizard（MFC ActiveX 控件生成向导）是创建控件的最快方法。这个向导将大部分接口细节管理起来，使你最终得到控件逻辑的一个轮廓。事实上，使用ATL方法创建控件通常要使开发人员用两倍（于MFC方法）的时间。显然，这还取决于诸如控件复杂度以及程序设计经验之类的因素。
维护 MFC和ATL共有的特是使得用它们产生的代码，比那些从头开始写出的代码，维护起来要容易得多。但是，当对一个原来的控件作一些与维护有关的变化（比如出小毛病后修改掉它）时，就要考虑一下了。ATL控件通常包含不多的由向导生成的“锅炉钢板型”（即难懂的）代码。因为对自己写出的代码会更加熟悉，因而改变起来就更快更容易。另一方面，Microsoft维护着你使用的MFC中所有控件，这就是说，许多小毛病的改正和其它种类的更新，只要简便地再把代码编译一次，就可以自动地完成。在这种情况下作何种选择，确实难以回答，因为没有办法能确切地确定在将来你需要对你的控件作什么样的维护变化。
控件大小 如果要创建最小的ActiveX控件，那么采取ATL方案最好。ATL把控件的各方面控制权都留给你，使得你可以方便地手工调节控件的每个元素，而不至于陷于MFC专用代码的泥潭。基于MFC的控件不仅规模大，而且在用户使用这一控件之前还必须下载MFC库，这个库也有相当多的代码。
学习难度 由于创建ATL控件时不得不考虑更多的事情（比如接口），所以创建起来比MFC控件就更困难。多数情况下，先用MFC ActiveX ControlWizard（MFC ActiveX控件生成向导）创建几个控件，从中学习创建控件逻辑的规则，这样做是值得的。
技巧 如果你用惯了Visual C5.0的ATL，那么就尝试一下6.0版中新的ATL COM AppWizard（ATL COM 应用程序生成向导）。新的ATL COMAppWizard（ATL COM 应用程序生成向导）帮助你以比过去手工技术快得多的速度创建控件。但是，使用 MFC ActiveX Control Wizard（MFC ActiveX 控件生成向导）创建控件仍然要比使用 ATL COMAppWizard（ATL COM 应用程序生成向导）快得多。
兼容性 从定义可以看出，基于MFC的ActiveX控件要求客户将MFC 库安装到他们的机器上。但是，有好多种版本的MFC库在使用，而它们并不都是相互兼容的。如果用户下载了你的控件及其相关的库，但不能使用某些重要的应用程序，因为新库与它们的应用程序不兼容，这时该怎么办呢? 因为MFC库存贮于SYSTEM目录下，客户机仅能拥有一个版本，到那里到MFC库就能解决兼容性问题了。
使用的难易程度 MFC ActiveX Control Wizard（MFC ActiveX 控件生成向导）对你写控件代码的能力不作多少要求，所以它把它所拥有的一切都放进了控件之中。这意味着你最终可以得到十分丰富的接口，但其中有的对你来说或许用不着。这一功能性浪费，导致了控件规模的膨胀，并且使得它难于使用。
代码修改的难易程度 开始时，创建基于MFC的控件是非常容易的。因为向导把许多代码都添加好了，所以应用程序开发进程很快，你只需关注把你的控件做得出的细节。如果创建的控件投入使用后不需作什么修改，选择MFC显然是上策。但是，如果决定要更新控件时该怎么办? 你的源代码文件包括了大量代码，这些代码不是由程度员写出来的，需要用额外的时间去研究、理解它们。因此，如果计划经常会对代码作修改，那么选择ATL将是上策，因为，当控件中由程序员生成的代码出了什么事时，程序员处理起来就容易多了。
参考资料：/%D0%A1%D5%F2%D0%C4%C7%E9/blog/item/7a276006b55e47b0208819f.html