Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations derfloh on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
Question about DDE, ... Iis it used any more? 1
- Thread starter dkean4
- Start date
Olaf Doschke
Programmer
Last time I used it was also the first time I used it, and that was between two FoxPro applications.
If you want to communicate with another process you only have the choice if you can plan and implement both sides, otherwise, you depend on what's offered.
In VFP history, DDE was your only option before OLE automation became available. And so that is actually preferable.
If you want to go modern, then use interprocess communication (IPC) with shared memory or named pipes. Christof Wollenhaupt had a Session about this in a German dFPUG Conference.
I used this about 2015. It's not as easy to implement and quite error intensive and sensitive, but it's doable.
Here you have a starting point (VFP5/NT): I haven't tested, but I used the same API functions in Windows8 and 10, so this is still available in the same way.
Bye, Olaf.
Olaf Doschke Software Engineering
If you want to communicate with another process you only have the choice if you can plan and implement both sides, otherwise, you depend on what's offered.
In VFP history, DDE was your only option before OLE automation became available. And so that is actually preferable.
If you want to go modern, then use interprocess communication (IPC) with shared memory or named pipes. Christof Wollenhaupt had a Session about this in a German dFPUG Conference.
I used this about 2015. It's not as easy to implement and quite error intensive and sensitive, but it's doable.
Here you have a starting point (VFP5/NT): I haven't tested, but I used the same API functions in Windows8 and 10, so this is still available in the same way.
Bye, Olaf.
Olaf Doschke Software Engineering
Olaf Doschke
Programmer
..,. and if you simply ask about what Windows still supports: DDE is also still the mechanism that allows Windows to pass on command-line parameters to an already running process. For example (of the correct registry keys exist) to get a DBF opened with double click in an already running VFP IDE session instead of starting a new vfp9.exe process. Also to get this displayed in a browse instead of the new VFP9.exe process trying to compile the DBF and run it as if a PRG file name was passed in.
How that sepcifically works for the VFP9.exe is shown by Berezniker here:
But don't expect the same type of key works for any EXE, If an exe isn't programmed to react to certain topics and file types, this doesn't force it to happen. Take a close look at the keys listed here, they have a prerequisite of VFP installation having defined OLE types of files like Visual.FoxPro.Table and Visual.FoxPro.Program and they have defined reactions to "open" action, for example.
So the mechanism still works.
The main mechanims of DDE Exec are topics and actions. You can establish something similar to topics, at least, with multiple memory-mapped files. The two processes sharing memory obviously have to agree on several names and act on them as they need. It's simpler to only have one channel and think about a proprietary "protocol" of messages you exchange in it.
I'd say DDE will continue to be supported because it is not only a VFP feature to be able to pass command-line options to an already running IDE. But it can obviously also only cause wanted actions if the receiving process is programmed to react to something sent in via DDEexec.
So - if you don't realize - neither DDE nor shared memory can be used to force the other side to react or even just read what you send to it.
In shared memory, your process can create the memory-mapped file, and put something in, but the other process has to grab it from there actively. In DDEexec topics, the other process has to react to them. It's always an agreement, what works.
So, Well, in the end like any interface. In the other usual candidate for interop - OLE Automation - you can also only call methods and set properties when the OLE object model and interface you use offers it or you program it.
Bye, Olaf.
Olaf Doschke Software Engineering
How that sepcifically works for the VFP9.exe is shown by Berezniker here:
But don't expect the same type of key works for any EXE, If an exe isn't programmed to react to certain topics and file types, this doesn't force it to happen. Take a close look at the keys listed here, they have a prerequisite of VFP installation having defined OLE types of files like Visual.FoxPro.Table and Visual.FoxPro.Program and they have defined reactions to "open" action, for example.
So the mechanism still works.
The main mechanims of DDE Exec are topics and actions. You can establish something similar to topics, at least, with multiple memory-mapped files. The two processes sharing memory obviously have to agree on several names and act on them as they need. It's simpler to only have one channel and think about a proprietary "protocol" of messages you exchange in it.
I'd say DDE will continue to be supported because it is not only a VFP feature to be able to pass command-line options to an already running IDE. But it can obviously also only cause wanted actions if the receiving process is programmed to react to something sent in via DDEexec.
So - if you don't realize - neither DDE nor shared memory can be used to force the other side to react or even just read what you send to it.
In shared memory, your process can create the memory-mapped file, and put something in, but the other process has to grab it from there actively. In DDEexec topics, the other process has to react to them. It's always an agreement, what works.
So, Well, in the end like any interface. In the other usual candidate for interop - OLE Automation - you can also only call methods and set properties when the OLE object model and interface you use offers it or you program it.
Bye, Olaf.
Olaf Doschke Software Engineering
- Thread starter
- #4
- Thread starter
- #5
Olaf,
After some thinking, I do have a question for you. The reason for this inquest was that running a VFP app I often need a concurrent process running in the background which will not impact, on the currently running application, but which can provide essential and timely support. Using timers in the main VFP app appears to interrupt the Main application's process and the timers do not process as a Multi-thread. Their delays are all over the place because the app is running as a single thread, which seems to be timed (X amount of code per second). I understand that, but it would be nice to be able to run multiple apps and provide a more fluid or predictable timing when the Main App is happily doing its Main task and getting help from one or 5 other supporting apps. (You covered this above)
(The new inquest is this)
Of course, to complicate things, it would be nice to be able to hook into a Browser as well. Currently, I transfer files in the PC's file directory to do this or that. It is simple and puerile, although slow, because of the timers I use on both sides to check the availability of data. It works both ways, just fine, but if you know something more direct which does not have to make the Browser code sit and test if there is a file in the directory, that would be great. Basically, is there any equivalent to OLE that VFP could exploit for communication with, preferably, Google Chrome. The process of Transferring files has a long reaction time and it can be felt like hesitation or serious delay. I need a faster reaction because I use Crome's Speech Recognition, which at this time is superlative for recognizing speech.
By the way, thanks for thinking ahead as always, concerning Not being able to do more than respond to static functions. In OLE, when using VFP on the receiving end I send code which can be ExecScripted on the fly on the receiving end and I allow for 20 parameters to satisfy any call which may be executed dynamically. But that is just for VFP apps. (Might be able to do something similar in browsers, I will ponder on that.)
Anyway, thank you for your insightful ideas, Olaf.
Dennis Kean
Simplicity is the extreme degree of sophistication.
Leonardo da Vinci
After some thinking, I do have a question for you. The reason for this inquest was that running a VFP app I often need a concurrent process running in the background which will not impact, on the currently running application, but which can provide essential and timely support. Using timers in the main VFP app appears to interrupt the Main application's process and the timers do not process as a Multi-thread. Their delays are all over the place because the app is running as a single thread, which seems to be timed (X amount of code per second). I understand that, but it would be nice to be able to run multiple apps and provide a more fluid or predictable timing when the Main App is happily doing its Main task and getting help from one or 5 other supporting apps. (You covered this above)
(The new inquest is this)
Of course, to complicate things, it would be nice to be able to hook into a Browser as well. Currently, I transfer files in the PC's file directory to do this or that. It is simple and puerile, although slow, because of the timers I use on both sides to check the availability of data. It works both ways, just fine, but if you know something more direct which does not have to make the Browser code sit and test if there is a file in the directory, that would be great. Basically, is there any equivalent to OLE that VFP could exploit for communication with, preferably, Google Chrome. The process of Transferring files has a long reaction time and it can be felt like hesitation or serious delay. I need a faster reaction because I use Crome's Speech Recognition, which at this time is superlative for recognizing speech.
By the way, thanks for thinking ahead as always, concerning Not being able to do more than respond to static functions. In OLE, when using VFP on the receiving end I send code which can be ExecScripted on the fly on the receiving end and I allow for 20 parameters to satisfy any call which may be executed dynamically. But that is just for VFP apps. (Might be able to do something similar in browsers, I will ponder on that.)
Anyway, thank you for your insightful ideas, Olaf.
Dennis Kean
Simplicity is the extreme degree of sophistication.
Leonardo da Vinci
Olaf Doschke
Programmer
No idea from the top of my head, no.
I had to use an API that included USer interaction in a pop up window amd used the webbrowser control to keep that contained in the main VFP application, which runs full screen.
Through calling JS from VFP as described here:
Plus the JS internal mechanism of EventListener with callback.
Main ingredient 1: a JS function setting a global JS var to a VFP object:
Main ingredient 2: The callback function using that oVFP variable to make the VFP callback:
This JS function was a callback for some Browser internal stuff including a poop up winodow and HTML form etc, in the end receiving some response.
And the last ingredient is then to get this callback notice in VFP. Well, and that is just by having a property in the VFP object, which has an assign method. So the oVFP.property=... sssignment is triggering the VFP property_assign() method.
No file involved. But all that only works with IE automation or WEbbrowser Control, not with Chrome. You need to have the DOMDocument object reference to get at the Script object and call a JS function:
And as Rick hints, in JS function and variable names are case sensitive, in VFP not, so you have to define all lower case names.
And all this only works IE based, so there is no use of any Chrome specific JS component not available in IE.
Bye. Olaf.
Olaf Doschke Software Engineering
I had to use an API that included USer interaction in a pop up window amd used the webbrowser control to keep that contained in the main VFP application, which runs full screen.
Through calling JS from VFP as described here:
Plus the JS internal mechanism of EventListener with callback.
Main ingredient 1: a JS function setting a global JS var to a VFP object:
Code:
var oVFP;
function setref(dummy,oObj) {
oVFP = oObj;
}
Code:
function receiveMessage(event) {
if (event != null && event.data != null && event.data != "") {
let serverresponse = event.data;
oVFP.property = JSON.stringify(serverresponse, undefined, 4);
}
}
}This JS function was a callback for some Browser internal stuff including a poop up winodow and HTML form etc, in the end receiving some response.
And the last ingredient is then to get this callback notice in VFP. Well, and that is just by having a property in the VFP object, which has an assign method. So the oVFP.property=... sssignment is triggering the VFP property_assign() method.
No file involved. But all that only works with IE automation or WEbbrowser Control, not with Chrome. You need to have the DOMDocument object reference to get at the Script object and call a JS function:
Code:
oBrowser.Document.Script.setref(0,oVFPobject) && where oVFPObject is an instance of a class with a property_assign methodAnd as Rick hints, in JS function and variable names are case sensitive, in VFP not, so you have to define all lower case names.
And all this only works IE based, so there is no use of any Chrome specific JS component not available in IE.
Bye. Olaf.
Olaf Doschke Software Engineering
- Thread starter
- #7
Olaf
That would introduce one more hop. Chrome=>IE=>VFP. I have done a lot of IE=>VFP and that is trivial for me. Although Chrome=>IE adds to the complexity. Nevertheless, the idea is viable short of a more direct solution.
Maybe there is a way to monitor the Chrome Browser Tabs via the DOM from VFP directly? That would be boss. That would allow me to directly inspect a DIV for contents. Document.window...child[12]... I will have to do some experimenting. But if you have any ideas on how to attach a parasite hook into the Chrome browser... Anyway, wishful thinking. I will start messing with it.
Thank you so much, Olaf... Always inspiring to read your sharply honed answers...
Regards,
Dennis Kean
Simplicity is the extreme degree of sophistication.
Leonardo da Vinci
That would introduce one more hop. Chrome=>IE=>VFP. I have done a lot of IE=>VFP and that is trivial for me. Although Chrome=>IE adds to the complexity. Nevertheless, the idea is viable short of a more direct solution.
Maybe there is a way to monitor the Chrome Browser Tabs via the DOM from VFP directly? That would be boss. That would allow me to directly inspect a DIV for contents. Document.window...child[12]... I will have to do some experimenting. But if you have any ideas on how to attach a parasite hook into the Chrome browser... Anyway, wishful thinking. I will start messing with it.
Thank you so much, Olaf... Always inspiring to read your sharply honed answers...
Regards,
Dennis Kean
Simplicity is the extreme degree of sophistication.
Leonardo da Vinci
Olaf Doschke
Programmer
No, for sure the detour through IE won't help, if you do need to automate Chrome. I don't see how you can, there is no OLE object model and automation concept from Google for Chrome.
The only chance to make use of this "JS automaton" via IE is, you can make calls in IE to a Speech API that runs server-side, not client-side. And then you likely won't need to go through a client browser or browser control but through HTTP protocol.
As far as I glimpse about the Chrome Web Speech API it makes use of some server-side functionality to which audio is sent for detection, this doesn't run offline in the Chrome Browser alone.
On there is a note:
So this isn't a Chrome internal feature, it's a Google Cloud feature.
Your developer endpoint to this is not a WEb Service API endpoint URL but the Chrome SpeechRecognition object.
Bye, Olaf.
Olaf Doschke Software Engineering
The only chance to make use of this "JS automaton" via IE is, you can make calls in IE to a Speech API that runs server-side, not client-side. And then you likely won't need to go through a client browser or browser control but through HTTP protocol.
As far as I glimpse about the Chrome Web Speech API it makes use of some server-side functionality to which audio is sent for detection, this doesn't run offline in the Chrome Browser alone.
On there is a note:
MDN Web Docs said:
So this isn't a Chrome internal feature, it's a Google Cloud feature.
Your developer endpoint to this is not a WEb Service API endpoint URL but the Chrome SpeechRecognition object.
Bye, Olaf.
Olaf Doschke Software Engineering
Olaf Doschke
Programmer
Now, the question I would have to you is, how you manage data exchange so far? With user manual intervention? You said you work with files for data exchange?
In the end, as far as I quoted, you're doing speech recognition in Google's Cloud, which means this always will involve uploading a recording or current microphone audio stream to the cloud to get back the recognized text. It'll be slow anyway, as it does not run locally, you only have your entry point in the local Chrome Javascript runtime.
Bye, Olaf.
Olaf Doschke Software Engineering
In the end, as far as I quoted, you're doing speech recognition in Google's Cloud, which means this always will involve uploading a recording or current microphone audio stream to the cloud to get back the recognized text. It'll be slow anyway, as it does not run locally, you only have your entry point in the local Chrome Javascript runtime.
Bye, Olaf.
Olaf Doschke Software Engineering
- Thread starter
- #10
Olaf
I have a 200Mb bandwidth on my private line. The Speech Recognition is instantaneous on Google. At the max it may take 2 seconds for 5 words and you can actually see 5 or 6 guesses which Google makes as it improves the recognition and overwrites the former guesses. It is fascinating to watch. I have used MS's SDK versions 5.x for speech 15 years ago and it is miserably slow and it misses 9 out of 10 times unless you train yourself to speak like a News reporter. I designed a website on my local PC which takes advantage of Google's Speech recognition. It is very effective for me. I do not remember it making a mistake, in the last 4 years, unless I mumble something which even I can't interpret. I know that they use grammar to complete the recognition, but it is so good I am blown away with it. Google's SR is next to none.
Speach processing is not a problem. My little Website conveys the sentence into a file and drops it into a particular directory. Using timers to check if a file is waiting, in a designated directory, rips into the processing of my main app. It makes my app stutter because the engine is always cooking something. I need something which will be "interrupt" driven. The interrupt will stuff data into the engine and process the sentence.
Come to think of it, I will have to separate this into 2 separate apps. Yeah, I was trying to support the UI and process speech. It would be nice if separate threads could run concurrently in VFP. Maybe that is what I should have asked you. I heard about multithreading in VFP, a long time ago. But I have no clue how to deal with that. Any ideas would be appreciated. And if you want me to post a new question, let me know.
You actually helped me again, to rethink this madness.
Thanks again, Olaf...
Dennis Kean
Simplicity is the extreme degree of sophistication.
Leonardo da Vinci
I have a 200Mb bandwidth on my private line. The Speech Recognition is instantaneous on Google. At the max it may take 2 seconds for 5 words and you can actually see 5 or 6 guesses which Google makes as it improves the recognition and overwrites the former guesses. It is fascinating to watch. I have used MS's SDK versions 5.x for speech 15 years ago and it is miserably slow and it misses 9 out of 10 times unless you train yourself to speak like a News reporter. I designed a website on my local PC which takes advantage of Google's Speech recognition. It is very effective for me. I do not remember it making a mistake, in the last 4 years, unless I mumble something which even I can't interpret. I know that they use grammar to complete the recognition, but it is so good I am blown away with it. Google's SR is next to none.
Speach processing is not a problem. My little Website conveys the sentence into a file and drops it into a particular directory. Using timers to check if a file is waiting, in a designated directory, rips into the processing of my main app. It makes my app stutter because the engine is always cooking something. I need something which will be "interrupt" driven. The interrupt will stuff data into the engine and process the sentence.
Come to think of it, I will have to separate this into 2 separate apps. Yeah, I was trying to support the UI and process speech. It would be nice if separate threads could run concurrently in VFP. Maybe that is what I should have asked you. I heard about multithreading in VFP, a long time ago. But I have no clue how to deal with that. Any ideas would be appreciated. And if you want me to post a new question, let me know.
You actually helped me again, to rethink this madness.
Thanks again, Olaf...
Dennis Kean
Simplicity is the extreme degree of sophistication.
Leonardo da Vinci
Olaf Doschke
Programmer
Well, yes, multithreading even became a project on Codeplex. But MTmyVFP didn't migrate to Github, I don't find it anymore. And Google Chrome warns to visit the old codeplex site. Either it's really currently infected or somebody bought the domain and redirects requests somewhere.
There are possibilities to react to filesystem changes and as you deal with an audio file that's your best deal for that. But as you run a webserver, what are you really struggling with? You can make requests and wait for responses asynchronous.
Is it the multiple responses coming in? You would go for Winsock for that and have multiple DataArrival callbacks.
Also, I see Google API is not only usable by JS, you can use it directly: So why fumble with an unautomatable Browser?
Bye, Olaf.
Olaf Doschke Software Engineering
There are possibilities to react to filesystem changes and as you deal with an audio file that's your best deal for that. But as you run a webserver, what are you really struggling with? You can make requests and wait for responses asynchronous.
Is it the multiple responses coming in? You would go for Winsock for that and have multiple DataArrival callbacks.
Also, I see Google API is not only usable by JS, you can use it directly: So why fumble with an unautomatable Browser?
Bye, Olaf.
Olaf Doschke Software Engineering
- Thread starter
- #12
Olaf
You are a veritable Encyclopedia! It looks very interesting. I am not proficient with C#. I worked with it for 6 months, but not confident that I can master it in a hurry. And I have no Cloud experience. Also, there is a price tag for Google Cloud. But it sounds like an ideal solution, Olaf. You rock!
You made me rethink things and I decided to get a handle on Chrome via OLE and remote keypress in "Chrome" after I redesign the site with all the function buttons positioned in the upper left region. With the handle on Chrome, I can initiate various processes and read the text returned. That can be done in a single thread without timers. I have done that 10 years ago with a variety of non-OLE compatible apps like Quickbooks... and it worked great. Total control over the remote apps. My local site is super simple and there should be no big issues.
Thanks for all your advice. You are a king!
Dennis Kean
Simplicity is the extreme degree of sophistication.
Leonardo da Vinci
You are a veritable Encyclopedia! It looks very interesting. I am not proficient with C#. I worked with it for 6 months, but not confident that I can master it in a hurry. And I have no Cloud experience. Also, there is a price tag for Google Cloud. But it sounds like an ideal solution, Olaf. You rock!
You made me rethink things and I decided to get a handle on Chrome via OLE and remote keypress in "Chrome" after I redesign the site with all the function buttons positioned in the upper left region. With the handle on Chrome, I can initiate various processes and read the text returned. That can be done in a single thread without timers. I have done that 10 years ago with a variety of non-OLE compatible apps like Quickbooks... and it worked great. Total control over the remote apps. My local site is super simple and there should be no big issues.
Thanks for all your advice. You are a king!
Dennis Kean
Simplicity is the extreme degree of sophistication.
Leonardo da Vinci
-
1
- #13
Olaf Doschke
Programmer
I still have the feeling I could help you straighten this a bit more. As far as Google Cloud costs go they don't charge anything when you remain undera threshold, and since I guess you only have personal use and your API key is used shared, that might be sufficient.
If you go for Chrome again, you eleminate the need of your own webservice processing requests, anyway, automating a user interface, you create. Yes, I see how this can work stable. You might even be able to put the browser window off screen while doing that.
Bye, Olaf.
Olaf Doschke Software Engineering
If you go for Chrome again, you eleminate the need of your own webservice processing requests, anyway, automating a user interface, you create. Yes, I see how this can work stable. You might even be able to put the browser window off screen while doing that.
Bye, Olaf.
Olaf Doschke Software Engineering
- Thread starter
- #14
Olaf",
I will look into Google Cloud as per your advice. I do like that solution. For practical purposes, I will finish off my remote key idea so I can use it right away. I have done that years ago so I should be done tonight. Afterward, I'll start looking into the Google Cloud solution. I really like that idea. I will have to figure out a way to record my voice (in VFP) to a file. (High-quality recording). Any idea you have on that is welcome.
Thanks, Olaf
Dennis Kean
Simplicity is the extreme degree of sophistication.
Leonardo da Vinci
I will look into Google Cloud as per your advice. I do like that solution. For practical purposes, I will finish off my remote key idea so I can use it right away. I have done that years ago so I should be done tonight. Afterward, I'll start looking into the Google Cloud solution. I really like that idea. I will have to figure out a way to record my voice (in VFP) to a file. (High-quality recording). Any idea you have on that is welcome.
Thanks, Olaf
Dennis Kean
Simplicity is the extreme degree of sophistication.
Leonardo da Vinci
- Status
Similar threads
- Locked
- Question
