Advice sought on App Design, IPC threads Remoting etc

Will the user need to see the "console app" or is it purely a mechanism for running tasks the GUI wants to display the results of? Does the console app have to be a separate standalone application?

Regards

Richard Blewett - DevelopMentor
http://staff.develop.com/richardb/weblog

nntp://news.microsoft.com/microsoft.public.dotnet.languages.csharp/<#I*************@TK2MSFTNGP12.phx.gbl>

I have a GUI app and i have a console app that performs some processing. The
GUI app calls the console app to do processing at various times. The console
app will need to be run in a separate thread (in order to leave the UI
useable) however it will need to report various messages (strings) during
its processing to the GUI app's output window. Similar fashion to the output
window in visual studio.

In the old MFC days a nice way to do this was using the WM_COPYDATA message
and send the string to the window that way. However, i'd like to do it the
.NET way.

I have briefly looked at App Domains and .NET remoting and this seems like
it could do it. However that route looks a bit like using a sledge hammer to
bang in a nail. Are there any nice quick solutions? What would the proper
way to do something like this be?


---
Incoming mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.770 / Virus Database: 517 - Release Date: 27/09/2004

[microsoft.public.dotnet.languages.csharp]

"Richard Blewett [DevelopMentor]" <ri******@develop.com> wrote in message
news:un**************@TK2MSFTNGP12.phx.gbl...

Will the user need to see the "console app" or is it purely a mechanism for running tasks the GUI wants to display the results of? Does the console
app have to be a separate standalone application?

Hi Richard,
The console app is purley a mechanism for running tasks the GUI wants to
display the results of. Yes the the console app has to be a separate
standalone app.

Basically all i need is a mechanism to pass strings from the console app to
the GUI app. Events might need to be triggered on the GUI app to display
these messages.

John

The supported "out-of-the-box" mechanism is remoting for this type of interaction, but there are other mechanisms e.g. I wrote a shared memory wrapper [1] a while back.

If the console app is under your control (which it would have to be for either of the above mechanisms) I'm just wondering why it has to run as a separate process and not just be tasks spawned on to separate thread(s). It it also a separate application that is used standalone? Does it have a tendency to crash and so need resilence?

[1] http://staff.develop.com/richardb/we...5-39ca338d906d

Regards

Richard Blewett - DevelopMentor
http://staff.develop.com/richardb/weblog

nntp://news.microsoft.com/microsoft.public.dotnet.languages.csharp/<uF**************@TK2MSFTNGP12.phx.gbl>
"Richard Blewett [DevelopMentor]" <ri******@develop.com> wrote in message
news:un**************@TK2MSFTNGP12.phx.gbl...

Will the user need to see the "console app" or is it purely a mechanism for running tasks the GUI wants to display the results of? Does the console
app have to be a separate standalone application?

Hi Richard,
The console app is purley a mechanism for running tasks the GUI wants to
display the results of. Yes the the console app has to be a separate
standalone app.

Basically all i need is a mechanism to pass strings from the console app to
the GUI app. Events might need to be triggered on the GUI app to display
these messages.

John

---
Incoming mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.770 / Virus Database: 517 - Release Date: 27/09/2004

[microsoft.public.dotnet.languages.csharp]

"Richard Blewett [DevelopMentor]" <ri******@develop.com> wrote in message
news:#f**************@TK2MSFTNGP14.phx.gbl...

The supported "out-of-the-box" mechanism is remoting for this type of interaction, but there are other mechanisms e.g. I wrote a shared memory
wrapper [1] a while back.
If the console app is under your control (which it would have to be for either of the above mechanisms) I'm just wondering why it has to run as a
separate process and not just be tasks spawned on to separate thread(s). It
it also a separate application that is used standalone? Does it have a
tendency to crash and so need resilence?

The console app is also a command line utility that users can use separatly
if they wish. The intention is to have it operate in a similar fashion to a
file compressor utility, i.e. where the console app can compress files
individually but it is also used the the GUI to compress multiple
files.Thats the reason for separation.

I am using a call to System.Diagnostics.Process.Start("MyApp.exe") to start
the console app.
I have complete control over both apps. It does not have a tendency to crash
and resilence is not needed.

It's looking that ill go down the Remoting route. I'd rather not use a
shared memory system as i'd prefer to let the .NET framework handle any ipc,
but thanks for your link.