Using Global Variable for Inter Program Communication

[Panthaur]

I am looking to create an easy, simple inter-communiction system between 2 applications.

I have a c++ console app (technically not a dos app because it does require use of a dll) that I am writing a menu application for, and I want to be able to send messages back and forth between the 2 programs. I was thinking of trying to make use of global variables to achieve this communication, or possible a text file on the users hard drive.

Does anyone have any suggestions on:
a) Will this approach work?
b) How to achieve this communication in another way?

Thanks for the input!

Panthaur

 

[Panthaur]

bump.. anyone have any ideas?

 

[johnwm]

If this is a C++ question you will do better in the C++ forum - this is VB6

As far as I know in VB, a global variable is global to the app, not to the world.

If you want stuff visible one a single machine from app to app, you could look at using the registry. In VB you can use SaveSetting and GetSetting, or in VB or C++ you can use the registry APIs. For that you could start here:

http://www.mentalis.org/tips/tip3.shtml

________________________________________________________________
If you want to get the best response to a question, please check out FAQ222-2244 first

'People who live in windowed environments shouldn't cast pointers.'

 

[johnwm]

I forgot to say that if you find you need to bump, it probably means you're in the wrong forum, or your question isn't clear enough.


________________________________________________________________
If you want to get the best response to a question, please check out FAQ222-2244 first

'People who live in windowed environments shouldn't cast pointers.'

 

[Panthaur]

I apologize, I meant to say environment variable, and it is not a c++ question, because the app that I am writing is a Visual Basic based frontend for the c++ console app.

I'm just trying to create some sort of messaging system for the 2 apps to communicate, and I was wondering if using an environment variable would work.

Panthaur

 

[johnwm]

You could use an environment variable, but the registry is designed to store short stuff for apps. Did you try the references I gave earlier?

If you really want to use environment strings, look up the WshShell Object in VBHelp or here:

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/script56/html/wsobjwshshell.asp

________________________________________________________________
If you want to get the best response to a question, please check out FAQ222-2244 first

'People who live in windowed environments shouldn't cast pointers.'

 

[strongm]

What sort of messages?

 

[SemperFiDownUnda]

How should I do this.....let me count the ways.
I could use environment variables......I could but bad choice IMOH. They are designed for very static data that many systems will need and are really only there for backward compatibility. Also I'm unsure of the scope of them. I'm not sure how windows apps access them in regards to scope. I know if you open up 2 command windows each one maintains its own sandboxed set of environment variables thus using it as a inter app com method doesn't seem a good choice.

I could use a text file. Pretty simple method Just have to have a loop continiously looking at the text file. Just make sure you write everything to the text file at 1 time for a message or you'll have to right your parser to handle fragmentation

I could use COM. Your VB App then could just fire off events to the C++ console app

I could use TCP/IP or even UPD to send messages...this is pretty much like text file in implimentation except if facilitates 2 way communication.

I could use pipes same deal just different protocall.

I could use a database, agian like the text file but bit better for 2 way communication.

Really depends on what you want to do, how fast, etc.

 

[Panthaur]

Hmm, I think that the registry might be the way to go. At least the easiest. Or maybe the text file approach would be a good choice too. Thanks for the tip on writing all data out at once to avoid fragmentation. Makes a lot of sense and could avoid a lot of hassles.

Panthaur

 

[Hypetia]

Panthaur, you may try this method.

Both applications should call the RegisterWindowMessage function to obtain a unique message id for communication between two applications.

One application will call SendMessage with HWND_BROADCAST sending the message obtained by the RegisterWindowMessage function.
The broadcasting application, may pass a window handle in wParam or lParam parameter.

The other application will intercept this unique message used between two applications and obtain the window handle of the calling application.
In response, it may also call SendMessage in the same way to send a window handle to the first application.

After both the applications know the window handles of each other, they may stablish further extended communication directly with each other using WM_COPYDATA message which allows to pass byte arrays (or strings) as well.

However, this is not necessary. If you do not need to pass byte arrays or strings then the two applications may also communicate with each other solely with the message returned by RegisterWindowMessage, without even knowing the window handles of each other.

I have used the first method to pass string data between two applications using WM_COPYDATA.

There is a problem with this method that it requires both applications to have a window for communication with each other via SendMessage. I think this will not be available with your console program.

If this method does not suit your needs then there is another choice. DDE...

 

[Panthaur]

I really like the idea, but yes, with the console app, I don't think I would be able to use this messaging properly. Can you go into more detail about DDE? I'm going to do a web-search as well, but maybe your experience with it would be helpful too.

Thanks,
Panthaur

 

[Hypetia]

Unfortunately, I can't help you about DDE. Because I have not done DDE in VB. In fact, I tried to do it in VB many times but always failed. All of the efforts always ended in a VB crash.
Although always unsuccessful, I believe that it can be done in VB too.

You have to rely on other resources or may be someone who has done it in VB may help you.

 

[cgfiend]

I don't know about C++ programming, but communicating with a DDE compatible application is simple to do in VB. In fact, it's only a few lines. I was in need of a solution much like yourself. I wanted to write an app to communicate with mIRC and send files upon a request. mIRC had the info in docs as to what I needed to use for parameters, which made it easy for me to send ANY command to mIRC. The kick was I couldn't send a command back to my program via DDE because mIRC only had a few DDE commands for returning specific data. So, my workaround was to use DDE for my app to send commands to mIRC and ran an app via command line using parameters to pass back data I needed. Getting back to DDE... Here's a few lines of VB code that works with mIRC:

'Link mode sets how the communication goes--see VB6
'docs "LINKMODE"
If Text1.LinkMode = vbNone Then
'The LinkTopic consists of an app identifier and
'a keyword separated by |, the keyword tells the
'app what kind of message you're sending and is
'determined by what was programmed into the
'app (in this case MIRC) DDE-wise.
Text1.LinkTopic = "MIRC|COMMAND" ' Set link topic.
Text1.LinkMode = vbLinkManual ' Set link mode.
End If

'Use a text box as a way to link to MIRC thru DDE
'Simply send the command you want. See MIRC docs
'for specifics on how it works. Cmd is a string
'containing the command to execute in mIRC. Again,
'this could be anything, not necessarily a command
'depends on the app you're talking to
Text1.LinkExecute "/dde mirc command " & Chr$(34) & Chr$(34) & " " & Cmd

 

[Panthaur]

I actually went the route of using the registry and some custom routines to send and receive data back and forth between the 2 apps I'm working with. It is coming along quite nicely and also rather quick.

Thanks for all you assistance,
Panthaur

 

[strongm]

In that case, I'd read the guidelines about registry use very carefully, if I were you

 

[Panthaur]

What do you mean? Can you elaborate or provide a link?

 

[Panthaur]

Strongm,

Can you give any links to some guidelines regarding registry use, or can you elaborate any more as to what you mean?

Thanks,
Panthaur

 

[strongm]

I'm trying to find the relevant ones, honest. The executive summary is that the registry was designed as a "system-defined database in which applications and system components store and retrieve configuration data" and Microsoft suggest that "An application should store configuration and initialization data in the registry, and store other kinds of data elsewhere". Additionally, the Registry is not in any sense a high-performance database, and it can take several seconds after comitting a registry entry before it is actually written to the registry

 

[Panthaur]

Essentially what I have done is have 2 registry entries, called ch1 and ch2 respectively, ch1 is a command, ch2 is data... the c++ app can both save and retrieve messages to either channel, as can the VB Menu program. I currently have them sending messages back and forth at 50ms rates. It takes less than 2 seconds to transmit all startup data and get the menu program ready to talk.

All in all, it seems to be working quite well. My whole thing was to make it simple and quick, which it appears to be. I'm thinking that what I might do is write a testing program and have it run non-stop for a week or so using the method I described above. I figure if it functions OK for a week or more, I shouldn't have a problem for normal use of the application.

What do you think?

Panthaur

 

[strongm]

If it works for you, then go for it. Myself, I wouldn't use the Registry for this; I'd probably use named pipes or mailslots