Multi Application Communication

Hello

I have two Windows forms applications that both access the same set of data from a database. What I would like to have is that these two programs be seperate, however if application #2 is running and the user clicks on an button in application #1, that application #1 fires an event that application #2 can pick up and pass data which would be the ID number of the record in the database. What is the easiest way to do this with the .NET Framework? I don't want to have to setup a server or service if possible

Thanks.

Justin
Fri May 14 22:09:44 CDT 2004

Many methods. However, the .NET way to do things is remoting. Remoting
isn't easy by any stroke of genious though. The clipboard is another
possibility
and you can set up clipboard viewers (your apps) and publish data that way.
Not the most efficient I'd say. Finally, you have good old fashioned windows
messages under a WinForms environment. This is probably the best way to
get something simple going, but more complex data types become a bit harder.

What you are looking for here is cross-process communication. In order for
this to work, managed processes need channels to talk on. Again, that is
remoting.
Of course Windows also provides channels and that is where the windows
messaging sub-system comes in.


--
Justin Rogers
DigiTec Web Consultants, LLC.
Blog: http://weblogs.asp.net/justin_rogers


"virtualswp" <anonymous@discussions.microsoft.com> wrote in message
news:30EDF737-ED12-4FD2-A653-9FDA2AF076F5@microsoft.com...
> Hello,
>
> I have two Windows forms applications that both access the same set of data
from a database. What I would like to have is that these two programs be
seperate, however if application #2 is running and the user clicks on an button
in application #1, that application #1 fires an event that application #2 can
pick up and pass data which would be the ID number of the record in the
database. What is the easiest way to do this with the .NET Framework? I don't
want to have to setup a server or service if possible.
>
> Thanks.

anonymous
Sat May 15 00:16:03 CDT 2004

Thanks Justin, that gets me going on the right track, I will take a look at those few ideas

----- Justin Rogers wrote: ----

Many methods. However, the .NET way to do things is remoting. Remotin
isn't easy by any stroke of genious though. The clipboard is anothe
possibilit
and you can set up clipboard viewers (your apps) and publish data that way
Not the most efficient I'd say. Finally, you have good old fashioned window
messages under a WinForms environment. This is probably the best way t
get something simple going, but more complex data types become a bit harder

What you are looking for here is cross-process communication. In order fo
this to work, managed processes need channels to talk on. Again, that i
remoting
Of course Windows also provides channels and that is where the window
messaging sub-system comes in


--
Justin Roger
DigiTec Web Consultants, LLC
Blog: http://weblogs.asp.net/justin_roger


"virtualswp" <anonymous@discussions.microsoft.com> wrote in messag
news:30EDF737-ED12-4FD2-A653-9FDA2AF076F5@microsoft.com..
> Hello
>> I have two Windows forms applications that both access the same set of dat
from a database. What I would like to have is that these two programs b
seperate, however if application #2 is running and the user clicks on an butto
in application #1, that application #1 fires an event that application #2 ca
pick up and pass data which would be the ID number of the record in th
database. What is the easiest way to do this with the .NET Framework? I don'
want to have to setup a server or service if possible
>> Thanks

DalePres
Sat May 15 08:27:16 CDT 2004

If there is only one event, or a very few events, that you want to handle
this way, you could just use the Win32 API SendMessage method. See
http://www.thescarms.com/vbasic/PassString.asp for an example of how to do
it in VB. It can easily be adapted to VB.Net or C#.

Another simple way to do it is to use MessageQueues. You can spawn a
separate thread on Application #2 to listen for a message and respond when
it comes. This is probably the simplest solution - probably the fewest
lines of code to implement - but you have to install the MessageQueue
Service in your Windows Components section of Add/Remove Programs.

Good luck,

Dale

"Virtualswp" <anonymous@discussions.microsoft.com> wrote in message
news:93809AA4-71C9-4DD9-B1D9-C1EB2EBF0687@microsoft.com...
> Thanks Justin, that gets me going on the right track, I will take a look
at those few ideas.
>
> ----- Justin Rogers wrote: -----
>
> Many methods. However, the .NET way to do things is remoting.
Remoting
> isn't easy by any stroke of genious though. The clipboard is another
> possibility
> and you can set up clipboard viewers (your apps) and publish data
that way.
> Not the most efficient I'd say. Finally, you have good old fashioned
windows
> messages under a WinForms environment. This is probably the best way
to
> get something simple going, but more complex data types become a bit
harder.
>
> What you are looking for here is cross-process communication. In
order for
> this to work, managed processes need channels to talk on. Again,
that is
> remoting.
> Of course Windows also provides channels and that is where the
windows
> messaging sub-system comes in.
>
>
> --
> Justin Rogers
> DigiTec Web Consultants, LLC.
> Blog: http://weblogs.asp.net/justin_rogers
>
>
> "virtualswp" <anonymous@discussions.microsoft.com> wrote in message
> news:30EDF737-ED12-4FD2-A653-9FDA2AF076F5@microsoft.com...
> > Hello,
> >> I have two Windows forms applications that both access the same
set of data
> from a database. What I would like to have is that these two
programs be
> seperate, however if application #2 is running and the user clicks on
an button
> in application #1, that application #1 fires an event that
application #2 can
> pick up and pass data which would be the ID number of the record in
the
> database. What is the easiest way to do this with the .NET
Framework? I don't
> want to have to setup a server or service if possible.
> >> Thanks.
>
>
>