2>、COM/DCOM之所以被认为是一种二进制标准,是因为它是一种在应用程序被编译成二进制机器码之后才起作用的标准;
3>、COM/DCOM不是一种面向对象语言,它也不指定一个应用程序如何构造,它是一种标准,它指明一种组件模型和使组件之间能够相互操作的编程需求。COM/DCOM组件可以运行在单一进程、不同进程、甚至是远端机器;
4>、COM/DCOM组件可以通过许多编程语言来创建。许多面向对象语言,诸如C++,都提供可简化COM/DCOM组件实现的编程机制;
5>、COM/DCOM定义了一个COM/DCOM组件的核心实质。一般来说,一个软件组件由一组数据以及管理这些数据的函数构成。一个COM/DCOM组件是这样的一种软件组件,它专门通过一组或多组相关的函数存取组件数据。这些函数集合称为接口,而接口的函数称为方法。对COM/DCOM来说,它需要的唯一的调用接口方法的途径就是指向接口的指针;
6>、编译好的COM/DCOM组件是不能修改的,要增加新的功能只能由开发商对组件源码进行修改、更新,然后重新编译生成新的COM/DCOM组件;
4、DCOM服务器的配置:
DCOM的调用: 必须通过Proxy/Stub对象,并且是通过RPC协议; CoClass的CreateRemote方法(Create调用本地);
Proxy: 远程COM对象在应用程序执行中的影象(Image),封装应用程序的调用信息;
Stub:接受Proxy调用信息,再使用这些信息调用真正的DCOM对象;然后调用结果回传给Proxy,由Proxy回传给应用程序;
RPC(Remote Procedure Call): 通信协议,使用DCOM时必须激活;
SCM(Service control Manager):Windows服务管理器,管理EXE服务器的启动和停止
线程模型: 同COM的模型;独立模式和自由模式
工作后的能力培养一定是问题和实践驱动型的,而不是理论驱动实践的。实践驱动在问题解决后才能够有真正的验证标准,才可能进行实践活动的分析和总结,形成分析解决问题的方法用于下一次实践。没有问题,没有项目的实战往往很难培养独挡一面的能力,即时有再完备的理论基础也没有用。这也正是我们谈的工作要主动承担任务,并乐于帮助他人解决问题的原因,很多时候解决问题越多积累的经验越多。
Delphi 应用程序内嵌word几种方法的比较:
对几种方法的难易程度的判别
a.通过Delphi的控件TOleContainer 将Word嵌入
这是最简单的Ole嵌入,能够直接将Word文档调用,只需要使用ToleContainer.Run就可以将Word文档直接启动。且这样启动的Word文档与Delphi程序是一个整体(从界面上看),但是它存在不可克服的缺点,即不能通过Delphi控制Word文档,也就不能实现将灵活操纵Word的目的。
b.使用Delphi提供的Servers控件调用Word,使用Word的属性。word中activex控件
使用Delphi的Servers控件来操纵Word,在编程时Delphi能够实现代码提示,总体上看能够较好的实现Delphi对Word的控制,但是还有一些Word的功能不能在Delphi中调用(比如自己编写的VBA宏代码)。
且实现功能时本来在VBA代码中可选则参数在Delphi调用的时候必须添加,否则,连编译都不能通过。
这种方式启动的Word与Delphi程序分属两个窗体。此办法仅能作为一个参考。
c.通过真正的Com技术,将Office软件目录中文件MSWORD9.OLB中的类库全部导入Delphi中,利用Com技术编程,利用真正的Com技术,将MsWord9.OLD文件类库导入,然后利用Com技术进行使用。
整体上类似使用Delphi的Servers控件,稍微比Servers控件麻烦,优缺点与Servers控件相同。
d.使用CreateOleObject将启动Word,然后以Ole方式对Word进行控制。
这种办法是使用以CreateOleObjects方式调用Word,实际上还是Ole,但是这种方式能够真正做到完全控制Word文件,能够使用Word的所有属性,包括自己编写的VBA宏代码。
与Servers控件和com技术相比,本方法能够真正地使用Word的各种属性,和在VBA中编写自己的代码基本一样,可以缺省的代码也不需要使用。
本方式启动的Word与Delphi程序分属两个窗体。
缺点是使用本方法没有Delphi代码提示,所有异常处理均需要自己编写,可能编写时探索性知识比较多。
本文来自电脑杂谈,转载请注明本文网址:
https://www.pc-fly.com/a/jisuanjixue/article-46133-8.html
怎么就不能科学一点地去想想失足妇女合法化呢