Wiki Home

DDE


Namespace: WIN_COM_API
Dynamic Data Exchange (DDE) - Win3.x 16 bit technology to allow interapp communication.

For example, DDE made it possible to insert a spreadsheet chart into a document created with a word processor. Whenever the spreadsheet data changes, the chart in the document changes accordingly.

It was supplanted by OLE, which provided greater control over shared data.

VFP still doesn't allow you to write an OLE automation interface for your apps, but you can give them a DDE interface. For a sample showing how to use DDE to control a VFP App, see DDEto VFP

Naw, creatting VFP OLE Automation is easy. See Fox OLEAutomation Example

OK - My point was poorly worded. It's very difficult to control a running app (for example to make an already visible form started as part of my app display a particular record) from another using OLE Automation. The kind of thing I mean is what we do with Word or Excel where we can hook into an already running instace of it from an app (like a VFP app) and do things to/with it. I agree that we can make COM servers.

Some pseudo-code of the sort of thing I'd like to be able to do with my app (for example, from another VFP process) might be:

local loMyCRMApp && note the juciciously placed "M"
loMyCRMApp = getobject('CRMMain.Application')

loMYCRMApp.DisplayCustomer(77656)
loMyCRMApp.ShowWindow('ContactList')
loMyCRMApp.BringToTop()


My point was that you can do this with a DDE interface. -- Andrew Coates

You can also do this in Fox with some planning. For example, the Class Browser (which comes with source code so you can see it work)
DO (_BROWSER)
_oBrowser.opencatalog(HOME()+"ffc\_base.vcx")
_oBrowser.seekclass("_line")
_oBrowser.viewcode()

You need to program the interfaces, but it's often as simple as not putting event and method code in controls, but delegating to the form itself. Thereafter from any client you can refer to _VFP.ActiveForm. It's easy, though I agree not obvious.-- Steven Black

I've snipped bits of this from the DDEto VFP topic because it doesn't seem to make sense to have this Thread Mode discussion in two places at once. Once it settles down, I'll refactor it all into one convenient place.

I understand how the Browser stuff works, and it works just fine if I create the instance of the fox app from the controlling application. What if I want to be able to control the same application from two (or more) possibly non-fox apps

The use case that springs immediately to mind is a CRM app I have written for a customer. When they get an e-mail or a phone call, they want to be able to, from Outlook or their phone software, display the customer's record in their currently active instance of the CRM app. I don't know how you would do this with OLE automation. I do know how you would do it with DDE. -- Andrew Coates

In the case of the object browser code above the first thing the code does is to create the browser object -- I want to get a reference to a currently running (stand-alone exe version of the) browser from outside fox, and if there's not one currently running, start one that stays active after my calling app has finished with it and that can be controlled by other apps as well.

Like this, in VFP but this is portable to any COM client environment.
* same sample, essentially, running from another instance of VFP.
xx=CREATEOBJECT("VisualFoxPro.Application")
xx.DoCmd("Do (_Browser)")
LOCAL loBrowser
lobrowser=xx.EVAL("_oBrowser")
lobrowser.opencatalog(xx.Eval("Home(1)")+"\ffc\_base.vcx")
lobrowser.seekclass("_line")
lobrowser.viewcode()
xx.Visible=.T.

I think this beats the pants off DDE...

I agree, but doesn't
xx=CREATEOBJECT("VisualFoxPro.Application")

need the dev version of VFP installed on the box? Not terribly royalty free. Won't suit my CRM app very well.

In addition to the above, I don't want to have to CREATEOBJECT() if there's already an instance running, I want to GETOBJECT() and control that instance.

Were you to create an EXE with the class browser built-in you could do pretty much as above. In other words, you do not need the dev version of VFP installed.

I don't know, maybe I'm being closed minded, but I would go to great extremes to avoid using DDE. Who knows, it may get removed from the OS at any time. -- Randy Jean

Randy, to an extent I agree with you, but I simply haven't found another way to do what I need to do using any other method. As for having DDE removed from the OS at any time, couldn't you say that about almost any feature? The fact that MS still appear to use it to communicate between Word and Excel, for example in Mail Merge, even in the latest incarnation of Office, seems to indicate that it's likey to be around for a while to come yet.


DDE is still in Windows Vista (though NetDDE has been removed) -- Stuart Dunkeld

OK, I've been playing with this a bit over the weekend (social life, what social life?) and I still can't get this to do what I want with OLE automation. I created a very basic form and class, compiled it into a project, ran the exe and tried to control it from VFP -- no dice. The source for my experiment is at ?_ VFP OLEExperimental Code.

Is it possible to create an Visual FoxPro.Application object (or any other automation object) referencing to an already running instance? (Like, by providing in the constructor parameters the processId for example.)

Andrew, how about using BINDEVENT to have your application respond to a Windows API event and let the other application trigger the API event, passing to it the CustomerID and requested formname as parameters. The question is which Windows API event to use. This would only work if your app is already running -- Alain Legrand

Category Definitions Category Windows OS Category C _ O _ M
( Topic last updated: 2006.12.19 11:16:05 AM )