求用 Delphi 编写 OLE Server 完整规范。 By BaKuBaKu(300分)

  • 主题发起人 主题发起人 BaKuBaKu
  • 开始时间 开始时间
B

BaKuBaKu

Unregistered / Unconfirmed
GUEST, unregistred user!
关于 OLE Server 以及相关的系列问题。
本人对于这方面认识比较肤浅,现在提出这样一个问题,是希望能够把我掌握的零碎的
知识贯通起来,并希望能够起到抛砖引玉的作用,引发各位的妙论,请高手不吝指教。
下面举出一个尽可能完整的实例,以便展开讨论:
我要求制作一个简单的图形编辑器,比如叫做“TGraphApp”,拥有 New 和 Open 方法,
和 Documents[n] 属性,用于访问它的文档对象。
然后是文档对象,比如叫“TGraphDoc”,可以完成简单的画点画线的功能,拥有画点
DrawPixel(X,Y) 和画线 DrawLine(X1,Y1,X2,Y2) 两个简单的 pubilc 方法,以及两个文
件操作方法:Save、Close,还包括一个变量 FileName, 记录的是文件名字。
为了简单起见,功能仅限于此。下面是实现要求:
1、上面所说的所有方法和属性都应该能通过 COM Interface 访问。
2、我需要能够在 Delphi 中使用 TOleContainer 或者是在 Word 等文档处理工具中通过
“Insert Object”插入一个这样的图形文档,比如叫做“Test Graph Document”。
3、这个文档插入后应该可以实时显示在 OleContainer 或 Word 文档中,通过 DblClick
能够激活我的编辑器进行In-Place Edit,修改后的结果能够实时反映在包容文档中,通
过鼠标的拖曳可以随意改变放置的位置。
4、当保存包容文档(如 Word 文档),应该能够参与整个复合文档的结构化存储流。当
然,还需要能够“Copy”,这样可以在另外的文档中“Paste”出来。

OLE Client 的功能可以暂不实现,这里只需要实现 Server 端就可以了,也就是说,
只需要支持把自己的文档嵌入别的应用程序中,没有必要支持嵌入别的应用程序的文档。
当然,如果能一并实现更好。

这样的应用程序现在已经是很常见,但是对于用 Delphi 如何从头至尾来写一个这样
的东东,我并没有经验,比如,应该实现哪些接口?怎样设计类结构等等。我希望能得到
一个详细的解决方案,用流行的话说,就是一个 Total solution 。
给出这一点分数并不能说明什么,只是想请高手不吝指教,另外,谢绝灌纯净水!
 
1、声明Imyface接口,有iunknown类型;
2、delphi2.0以上应该都有这个oleauto的demo的
3、也一样的道理,不过,要是能做到象公式编辑器之类的东西这样好的话,我就
不知道了,水平有限
4、同3
 
这个问题论坛上讨论过几次,结论是很困难 :-))
想这样做的人被推荐去看《Inside OLE 2》,可想而知是什么意思了吧!
这恐怕是delphi唯一的一个没有完全实现的windows技术。

我一直的观点是OLE/In place edit是过气的技术,M$都不推行了,
甚至可以说完全放弃了(我认为如果COM 和 OLE真的有什么不同的话,就是放弃了这一部分内容)。
你没见现在M$都是推荐用Ole aotumation server么?
因此我建议放弃这种想法。

VC的project天生有此能力,也不过是历史原因,现在意义已经不大了。
没有人会真正去用这种技术,正因为如此,连Ole Container的技术都已经没有任何的发展,
你看自从Delphi2以来的TOleContainer多少年一贯制,没有任何变化就知道了。
 
OLE/In place edit 现在其实还是有的,只不过现在增加了 Automation Server ,我个人
认为 In-place Edit 这个功能还是比较方便,尤其在处理 Compound Document 的时候。
其实我也不一定非要使用 Delphi 不可,VC++ 的方案也在考虑之列,只不过总是有遗憾的
感觉,用 VC++ 编程好像缺乏 Delphi 的灵气,如果说 VC++ 是一头朴实而强健的大象,那么
Delphi 就是一只敏捷的灵猫。
还是希望能够看到一个比较完整的 Solution 和技术讲解,不管使用什么平台、何种语言。
 
嗯,我们说得并不矛盾,Inplace Edit当然还有这样那样的价值,不过:
>>还是希望能够看到一个比较完整的 Solution 和技术讲解,不管使用什么平台、何种语言。

我想答案还是去看《Inside OLE 2》,其实看VC++源代码也可以,
似乎用VC++实现是easy enough,但是用Delphi实在有无从下手的感觉

ps:前面有一点没有说到,实际上ActiveX技术就是从inplace activate技术演化而来的,
不过变成了静态嵌入,不支持动态的server。总之,我的结论就是:
原来的“O.L.E.”被拆分为Automation Server和ActiveX Control,它们各实现了
一部分内容,而Compound document/Inplace Edit被废弃了。
 
《Inside OLE 2》?
 
我听着呢。
 
你老说Document被废弃了,是哪来的资料?
我记得是OLE被弄成了Automation、Active Document和ActiveX,没听说Document被干掉了啊
 
我一直只是说这是我的观点,没有资料。我说的被废弃,首先是说被广大开发者抛弃,
其次是说软件厂家(主要是M$,包括borland)没有再进一步增强功能(连这种迹象都没有)。
对比一下其他技术的快速,成熟发展,我觉得就足以证明了。
这都是我的直觉,我相信这是准确的,你想一想,平时极少有人和你提起过,
网上也极少看到过资料和讨论,你所使用过的软件也极少采用的技术,还能算什么呢?

Active Document实质就是Compound document的简单翻版,没有任何新意,乏善可陈。
只有微软假惺惺的说AD比原来有进步,可是似乎没有获得任何开发者,软件厂商的响应。
这一点,和于他同类的automation和ActiveX对比一下就知道了
因此,我简直想说AD都是被废弃的技术。不过,我还是采用最早的说法,就说是过气吧 :-))
 
这些天我又仔细地翻阅了一些 Delphi 的资料,发现 Delphi 对这样的应用的确是不支持,
当然不是说 Object Pascal 不能做,而是缺少相应的类库,就像原来用 TAPI 编程的时候,
只有 MFC 的 TAPI 可用,后来才出现 CB 上的 TAPI 类库,最后才有 Delphi 版的。
还有 ODBC 的配置,不知道有多少用 Delphi 的朋友为此伤脑筋,然而用 VC++ 的话,只
需简单地调用 OdbcAPI.h 里面的一个函数配置一下就可以了。
看来 Delphi 虽然号称比 VC++ 先进一个时代,但是 VC++ 凭借庞大的类库和资源优势与
之相比丝毫不落下风,真是应了一句老话:“好马还得配好鞍”。
不知道什么时候 Delphi 的类库才能真正赶上 VC 的规模,在此之前,俺只好再操起 VC++
这根大棒,钻到 Document/View 的古老的世界里去了。
 
欢迎继续发表高见!
 
同意,在任何系统上开发,资源是很重要的,所以才会出现Delphi-Jedi这样的组织,
这也确实是Delphi不能动摇VC地位的主要原因之一。

不过,具体就这个问题,恰恰是我得出前面结论的原因。因为Delphi作为Windows上主流
开发工具之一,必须支持Windows本身的绝大部分技术,否则他连现在的地位也没有。
大家也都看到了,Delphi Fan们不遗余力地扩充Delphi的资源,最后连VXD都“能做”了,
可是这个功能仍然没有任何发展。这首先是因为此功能十分复杂,不象翻译个头文件那样
简单,因此最好还是borland自己做。既然如此,如果这个技术十分重要,应用广泛,
不可或缺,那么不用我们提出,Borland早就做好了。所以我才得出这样的结论:
这已经是过时的技术,Borland根本就没想做,也不会影响Delphi的发展。

看看网上/本论坛上提出这个问题的时间和比例,也知道实际情况确实如此,
即使在VC的技术网站/论坛上,也鲜有讨论此问题的文章和帖子。

ps:ODBC API的Delphi接口早已available多年了,论坛上也有很多,你没注意?
 
听听课吧。
>>
 
关于 ODBC 的贴子见过不少,但是 ODBC API的 Delphi 接口的确是没有见过。惭愧!
 
ODBC已经是一种过气的技术了,大家不理也罢
还是好好地看看DCOM/COM技术吧。
 
来旁听的。
 
多人接受答案了。
 
意犹未尽么?
 
呵呵,不知道...
 
后退
顶部