I have a Windows app that I wrote that manages a bunch of test equipment. I am trying to write a console app that can control it, so for instance you type TellMyApp "do something" and the Windows app does it. I know it sounds stupid, but it seemed to be the easiest way for a third party app (which can execute a batch file) to perform the necessary control of my Windows app. So far it's working. I can use FindWindow then SendMessage to execute menu commands and simulate keyboard input just fine. I'm having trouble figuring out how to return info to my console app, for instance to read back a setting to verify it. My current scheme is to copy it to the clipboard from the Windows app and retrieve it using the console app. It works but it could easily get corrupted by some other application that uses the clipboard. Is there a better way? Should I just make the console app be a windows app with a message handler and use SendMessage to return data to the console? If I never call ShowWindow would it remain hidden while running? I was thinking in WM_CREATE to send the message, receive the returned data, and PostQuitMessage right away, so the life of the program would be a fraction of a second.
I realize this is probably not good technique, so I fully expect the Wrath of Clifford. :)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
While searching around MSDN, I found a page titled "Creating Named Shared Memory". A quick and easy method to have a console app read data from a GUI app is to have the GUI put whatever data you want into named shared memory, which in their example ends up in the page file. Then the console app can read the memory. The example functions are easy to follow, and I pasted them into my two apps and was exchanging data a couple minutes later. I still want to tackle the winsock approach, but for now this works.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2007-08-31
Cool, glad you got it working.
The shared memory technique is is the "File Mapping" technique mentioned in the article I posted. It is amongst the simplest and probably highest performance technique for bulk data transfer (so long as you control data consistency - i.e. make sure you don't read it while it is being modified), and enables random access to the data. Most OSs support similar techniques, but the API is not portable. Windows Sockets is not so different from BSD sockets and TCP/IP is itself ubiquitous.
Clifford
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
This is a crap way to approach the scenario. The "normal" approach would have a console program with all the relevant logic and the GUI as simple front-end.
That said, it should be fairly easy to use a custom message scheme (WM_USER and custom marshallings preferably provided by a DLL with shared access) to do what you want.
That said, (almost done) my preferred method would be localizing all the logic in a shared library and offer both the GUI and console as interfaces communicating, where appropriate, through named pipes or sockets.
Soma
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The problem is the Windows app is already completely done, so this is a really a patch - the "normal" approach doesn't apply unless I rewrite the Windows app. The rest of what you said is beyond me: custom marshallings, DLL with shared access, shared library, named pipes or sockets. I'm just a mechanical engineer, in over my head - I know nothing of these things. I wouldn't even know exactly what to google to find tutorials or example code. Any suggestions? Oddly enough, the phrase "DLL with shared access" has zero hits. I did find this at MSDN: "Using Shared Memory in a Dynamic-Link Library". Am I on the right track at least?
p.s. Your wrath is less wrathier than Clifford's.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
That may very well go down in history as the funniest thing ever said on this forum. At one point, before Wayne and I deleted several thousand threads, you could search my name and your choice of profanity and get at least a few hits.
Yes. That would certainly work, and much better than what you proposed.
Soma
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
That is funny - soma, unlike some others, frequently hides the ascerbic nature of his comments behind some very clever wording, but I have known him to bite quite a bit harder than pretty much anyone here over the years. (Even me)
Wayne
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2007-08-30
Exchange the information between the apps using TCP/IP (Windows Sockets). It has the advantage the apps need not even be on the same machine (or even the same OS; you could use BSD sockets on another platform). If they are on the same machine just use the IP address 127.0.0.1.
I have a Windows app that I wrote that manages a bunch of test equipment. I am trying to write a console app that can control it, so for instance you type TellMyApp "do something" and the Windows app does it. I know it sounds stupid, but it seemed to be the easiest way for a third party app (which can execute a batch file) to perform the necessary control of my Windows app. So far it's working. I can use FindWindow then SendMessage to execute menu commands and simulate keyboard input just fine. I'm having trouble figuring out how to return info to my console app, for instance to read back a setting to verify it. My current scheme is to copy it to the clipboard from the Windows app and retrieve it using the console app. It works but it could easily get corrupted by some other application that uses the clipboard. Is there a better way? Should I just make the console app be a windows app with a message handler and use SendMessage to return data to the console? If I never call ShowWindow would it remain hidden while running? I was thinking in WM_CREATE to send the message, receive the returned data, and PostQuitMessage right away, so the life of the program would be a fraction of a second.
I realize this is probably not good technique, so I fully expect the Wrath of Clifford. :)
While searching around MSDN, I found a page titled "Creating Named Shared Memory". A quick and easy method to have a console app read data from a GUI app is to have the GUI put whatever data you want into named shared memory, which in their example ends up in the page file. Then the console app can read the memory. The example functions are easy to follow, and I pasted them into my two apps and was exchanging data a couple minutes later. I still want to tackle the winsock approach, but for now this works.
http://msdn2.microsoft.com/en-us/library/aa366551.aspx
Cool, glad you got it working.
The shared memory technique is is the "File Mapping" technique mentioned in the article I posted. It is amongst the simplest and probably highest performance technique for bulk data transfer (so long as you control data consistency - i.e. make sure you don't read it while it is being modified), and enables random access to the data. Most OSs support similar techniques, but the API is not portable. Windows Sockets is not so different from BSD sockets and TCP/IP is itself ubiquitous.
Clifford
"I realize [...] of Clifford."
Probably, but I got here first.
This is a crap way to approach the scenario. The "normal" approach would have a console program with all the relevant logic and the GUI as simple front-end.
That said, it should be fairly easy to use a custom message scheme (WM_USER and custom marshallings preferably provided by a DLL with shared access) to do what you want.
That said, (almost done) my preferred method would be localizing all the logic in a shared library and offer both the GUI and console as interfaces communicating, where appropriate, through named pipes or sockets.
Soma
The problem is the Windows app is already completely done, so this is a really a patch - the "normal" approach doesn't apply unless I rewrite the Windows app. The rest of what you said is beyond me: custom marshallings, DLL with shared access, shared library, named pipes or sockets. I'm just a mechanical engineer, in over my head - I know nothing of these things. I wouldn't even know exactly what to google to find tutorials or example code. Any suggestions? Oddly enough, the phrase "DLL with shared access" has zero hits. I did find this at MSDN: "Using Shared Memory in a Dynamic-Link Library". Am I on the right track at least?
p.s. Your wrath is less wrathier than Clifford's.
"Your wrath is less wrathier than Clifford's."
LMAO!
That may very well go down in history as the funniest thing ever said on this forum. At one point, before Wayne and I deleted several thousand threads, you could search my name and your choice of profanity and get at least a few hits.
Yes. That would certainly work, and much better than what you proposed.
Soma
That is funny - soma, unlike some others, frequently hides the ascerbic nature of his comments behind some very clever wording, but I have known him to bite quite a bit harder than pretty much anyone here over the years. (Even me)
Wayne
(And I deserved it every time)
;)
Wayne
Exchange the information between the apps using TCP/IP (Windows Sockets). It has the advantage the apps need not even be on the same machine (or even the same OS; you could use BSD sockets on another platform). If they are on the same machine just use the IP address 127.0.0.1.
There are a number of other IPC methods (the clipboard being one of them): http://msdn2.microsoft.com/en-us/library/aa365574.aspx
There that wasn't so bad was it!?
Clifford
Excellent. Thanks to everyone for the advice. I like the idea of not having to be on the same machine, so I think I'll try TCP/IP.