One executable program send message to another executable program

[Guest]

I need to have one executable program (which I will refer to as PROG1) set
the value of a Windows Form textBox control located in another executable
program (which I will refer to as PROG2). PROG1 was developed with VB.Net
2005 and PROG2 was developed with VB 6.0. Both programs are running on the
same computer, which is running Windows XP professional SP2.

After PROG1 sets the textBox value in PROG2, I need for PROG2 to be
activated (that is, get focus).

I am thinking of using WIN32 API functions; however, I have no experience
with API functions, and I am not sure if this is the correct method to use.

Are there equivalent functions in VB.NET that can be used instead of WIN32
API functions?

Would you please point me in the direction I should take to accomplish this
task, and sample code in VB.Net would be very helpful.

Thanks very much.

JDH

 

[John Saunders [MVP]]

I need to have one executable program (which I will refer to as PROG1) set
the value of a Windows Form textBox control located in another executable
program (which I will refer to as PROG2). PROG1 was developed with VB.Net
2005 and PROG2 was developed with VB 6.0. Both programs are running on
the
same computer, which is running Windows XP professional SP2.

After PROG1 sets the textBox value in PROG2, I need for PROG2 to be
activated (that is, get focus).

I am thinking of using WIN32 API functions; however, I have no experience
with API functions, and I am not sure if this is the correct method to
use.

Are there equivalent functions in VB.NET that can be used instead of WIN32
API functions?

Would you please point me in the direction I should take to accomplish
this
task, and sample code in VB.Net would be very helpful.

I would point you at rewriting the VB6 program if at all possible.

Secondly, I'm a little confused: you say PROG1 is written in .NET, but
PROG2, written in VB6, has a Windows Forms Textbox?

Assuming that you have the opposite problem, there are some questions. For
instance, is PROG1 already written? Does it have to be an executable
program? Could it be a COM object or ActiveX control instead? Can the VB6
program be modified at all, perhaps just to have it call on a COM object?

 

[Guest]

John, Thanks for your response.

Both programs are already written, so the option of rewriting them is not
possible.

You said you are confused regarding the textBox in PROG2. Both programs are
standard executable programs, which are started in the normal way by clicking
on the exe file. The textBox is just a standard VB textBox control on a VB
form.

Yes, I am able to modify both programs.

You asked about COM objects. Both programs do reference a common ActiveX COM
module, which I am also able to modify. Is it possible to use the COM module
for sending messages between the two programs?

Thanks, Jerry

 

[John Saunders [MVP]]

John, Thanks for your response.

Both programs are already written, so the option of rewriting them is not
possible.

You said you are confused regarding the textBox in PROG2. Both programs
are
standard executable programs, which are started in the normal way by
clicking
on the exe file. The textBox is just a standard VB textBox control on a VB
form.

Yes, I am able to modify both programs.

You asked about COM objects. Both programs do reference a common ActiveX
COM
module, which I am also able to modify. Is it possible to use the COM
module
for sending messages between the two programs?

Well, I've never done it before, but I suppose you could write a "two-sided"
COM object. It would have to run out-of-process. The VB6 program could
subscribe to an event on that object. The .NET application could call a
method on the object. The method would be called, passing the information.
The event would then be fired, passing the information to the VB6
application, possibly by storing it in a property of the object first.

However, I have to say - when you find you need to add substantial new
functionality - even a new _kind_ of functionality - to a VB6 application,
it's time to plan to rewrite it. It's one thing to maintain legacy code if
it won't need to change radically, but when you find you need to do
something quite different from what the code already does, it's time to plan
to rewrite it in a technology better able to adapt.

If this were two .NET applications, they could simply use Remoting or
Windows Communications Framework to talk to each other. It would almost be
trivial.

 

[icxpbifyjs]

Hello! Good Site! Thanks you! iufaakgpaj