 |
AutoHotkey Community
Let's help each other out
|
| View previous topic :: View next topic |
| Author |
Message |
daonlyfreez
Joined: 16 Mar 2005
Posts: 755
Location: Berlin
|
 Posted: Wed Mar 23, 2005 4:09 pm Post subject: Dynamic Data Exchange (DDE) protocol support? |
 |
|
DDE
Support for DDE would allow to easily hook into DDE-savvy applications (e.g. Word, Excel)?
DDE (Dynamic Data Exchange) support would allow you for example to insert dynamically updating data into Microsoft Excel. From there one could apply ones own formulas, and have the results update dynamically with the data, or you could get the results back.
| Quote: | What is DDE and why is it totally different from COM?
DDE stands for Dynamic Data Exchange. That's exactly what it does, and nothing more. It sends data between applications using Windows messages according to a documented protocol. Saying that DDE is old-fashioned and is being replaced by COM is something you see repeated parrot fashion over and over again. DDE and COM do not work in the same way and they solve different problems.
Here are some points of difference:
- COM is synchronous, one party makes subroutine calls into the other and must wait until the call returns. If the called component is busy the caller is blocked until it becomes free. DDE is asynchronous, a well-programmed client sends a Windows message to the server and carries on processing. Windows holds the message and sends it to the server when the server is ready to process it.
- COM is complex to program but powerful. The client can manipulate objects within the server as if they belonged to the client. DDE is straightforward to implement but all it can do is transmit data. It can only control another application because the recipient can treat data as a command.
- COM works well when the client creates an instance of a server object or application for its own use. Programming a continuously running server, to which clients can attach when they wish, is possible but tricky. DDE of itself is incapable of creating objects (although OLE1 used it as a transport mechanism). The essence of DDE is that clients attach to an already running server.
- Applications using COM almost always need support DLLs such as the VB runtimes or MFC. Programs using DDE can be mean and lean and do not need extra support DLLs.
- COM interfaces are tightly specified and contained within the software component. Some documentation is normally built into the interface. The user of a COM component knows exactly which methods are available and how to call them. DDE interfaces are specified only in external documentation.
- Because of the tight interface specification, upgrading COM components can be a nightmare. With DDE the server or client can be changed independently.
- COM is frequently used to communicate with a DLL in the same process space (called an in-process server). Such as server is often termed an ActiveX control and has the extension OCX. Our DDClient and DDServer Visual Basic components are in-process servers. Using DDE to communicate between components of the same application is possible but has no benefits.
- COM communication with a remote machine is called DCOM (Distributed COM). If you make a DCOM call to a remote machine which does not respond, your program (or at least the thread making the call) is stuck. DCOM has a fixed built-in timeout which you cannot change. DDE with a remote machine is called NETDDE, it is used by the Hearts game and Chat which come with Windows. Timeout is controlled by the program.
- Under Windows 3.1 and 9x it is possible to crash the system by badly programmed DDE, because the message queue can be filled. NT does not crash in this way, COM does not suffer from the problem at all.
- DDE is totally "Bit blind", neither the client nor server can tell whether the other application is 16-bit or 32-bit. Indeed, the server cannot know whether the client is on the same computer or not. Connecting 16 to 32 bit COM components is not usually possible.
It is easy to see from the above points why a DDE server is the most widely used way of providing data obtained from any form of hardware interface.
In particular:
- The server can run continuously.
- It will probably serve a wide range of clients but can be updated without requiring them all to be recompiled.
- It is immune from the problems associated with different versions of the system DLLs on different machines.
- It can be small and self-contained.
- Clients cannot interfere with the running of the server by being slow or busy. |
_________________
(sorry, homesite offline atm) |
|
| Back to top |
|
 |
Nemroth
Joined: 07 Sep 2004
Posts: 262
Location: France
|
| Posted: Wed Mar 23, 2005 5:57 pm Post subject: |
|
|
I know it's probably a long way to implement it, but for my point of vue, I'd prefer the COM-ActiveX implementation. DDE is his forefather and is contained in COM. I would like the aspect of COM witch allow to control an other ActiveX app (Word, Excel and many others) from AHK, and not necessary the opposite, like in AutoIt 3 (an ActiveX DLL witch allow to control AutoIt 3 itself from other ActiveX applications (Excel, ...))
I spoke about that in COM and ADO support in AHK topic and I suppose it's a very hard job, but wait an see. |
|
| Back to top |
|
|
Chris
Site Admin
Joined: 02 Mar 2004
Posts: 10480
|
| Posted: Wed Mar 23, 2005 9:24 pm Post subject: |
|
|
Yes, COM support is tentatively planned. It is a relatively low priority because:
1) At a guess, probably less than 1% of AutoHotkey's users would use it.
2) It seems hard to implement, but that's probably because I know so little about it. |
|
| Back to top |
|
|
Nemroth
Joined: 07 Sep 2004
Posts: 262
Location: France
|
| Posted: Thu Mar 24, 2005 5:40 pm Post subject: |
|
|
| Chris wrote: | Yes, COM support is tentatively planned. It is a relatively low priority because:
1) At a guess, probably less than 1% of AutoHotkey's users would use it.
2) It seems hard to implement, but that's probably because I know so little about it. |
COM support is a good news.
I think that if users have the possibility to control Word or Excel or other ActiveX-COM apps compliants from AHK, they will be glad to do it by this powerfull way.
I'm agree it's probably hard to implement, and it isn't a high priority.
Perhaps in a first time is it interesting to implement, if you can, DDE support, as it is interesting to have it (it is the ancestor of COM), it can be a frist way to exchange data between apps in an efficiient maner.
Thanks, Chris, for your interest on this topic. |
|
| Back to top |
|
|
daonlyfreez
Joined: 16 Mar 2005
Posts: 755
Location: Berlin
|
|
| Back to top |
|
|
Chris
Site Admin
Joined: 02 Mar 2004
Posts: 10480
|
| Posted: Fri Mar 25, 2005 8:17 pm Post subject: |
|
|
| Thanks; those might come in handy. |
|
| Back to top |
|
|
zorglups
Joined: 04 Feb 2005
Posts: 22
|
| Posted: Tue Jan 17, 2006 9:39 pm Post subject: Just to let you know that it is maybe not 1% but 1,1% ;o) |
|
|
Chris,
I'm another user of autohotkey who is praying to get OLE support in ahk scripts.
- I saw the perl work-around.
- I agree that DDE could be a first step.
Anyway, best wishes for 2006 and thanks a lot for this really nice freeware.
Take care,
Pierre |
|
| Back to top |
|
|
|
|
You can post new topics in this forum
You can reply to topics in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|
FAQ
Search
Memberlist
Register
Profile
Log in to check your private messages
Log in
