How to share a form between multiple processes

Question

Summary:
I am working with C#.NET (framework version 2.0) in VS 2008, and I'm trying to determine the best way to create a Windows form that can be shared between multiple processes or multiple instances of a class.

Details:
I have a program that creates a status window (essentially a normal windows form with a text box).  Many instances of this program might be run at one time, however, and each one will create its own window with a text box.

I'd like to find a way to have all instances of this program use the same form.

Something like this:

• I start my program, the form window appears with a single text box.
• I start another copy of my program, and a second text box appears on the form window.
• I start a 3rd copy of the program, another text box appears on the same form window, etc...
• As I close each program, the associated text box disappears.
• As soon as all programs are closed, the form window itself disappears.

Any suggestions for how I might accomplish this?

Answer 1

Hey Daniel,

A couple quick questions for you:

Are you suggesting that the window that builds up the text boxes is the same application as the ones that you'll be running subsequently?

What is to happen on the other windows when you 'run' the app again?  Will they have windows?  If they don't, how would a user close them?

If they have windows, do the other forms have three text boxes on them, too?

Does the text box need to relay data to other forms?

Are you stuck on this approach, or are you open to a couple suggestions on alternate implementations?  I think folks could provide some good ideas if you can share more of your concept. 

If you can't, I hope the above questions will start to steer you towards an answer (like a server/client model where the first run spawns a server and client, each client registers with the server as it's run, and the server shuts down when there are no clients connected).

Out of curiosity (and to help limit scope of direction), is this for a school project or enterprise?

Cheers,

-jc

---

Me, coding and stuff: Mr. James

Answer 2

James,
Hopefully this will answer the questions.

I have a few normal programs that run at the console and generate output.
Call them: app1.exe, app2.exe, app3.exe, etc...

I also have another program that displays a single window, containing any number of text boxes.
Call it: window.exe

The first time I start the app1.exe program, the instance of window.exe is created, and a single textbox added to window.exe to show the output from app1.exe.
For each subsequent program I run (app2.exe, app3.exe, ...), a new textbox is added to instance of window.exe.
Finally, window.exe closes as soon as all the app*.exe programs finish running.

Were I writing this in VisualBasic 6, the program that displayed the window with all the text boxes (window.exe) would be an ActiveX EXE (only one global instance, standalone, persistent).  I'm trying to accomplish the same sort of thing in .NET.

I would be open to the idea of running a windows service of sorts to act as "window.exe" in my example; however, if there's a more straightforward way to accomplish this behavior, I'd be grateful to know.

And this is a work-related question; although more educational in nature, as I'm striving to better understand the .NET framework.

Thanks!
// Daniel

Answer 3

Hi again, Daniel,

Sorry for using a really high-level, technical description here, but what you're describing seems "icky".  ;o)  And, because it doesn't sound like you need the windows to actually talk to each other, a server/client approach is indeed too much.  

I would probably tackle the problem a little differently, so if you don't mind I'll quickly share that approach.  I would describe this as having a console from which you run your "sub" apps.

1) Layout the console window with a header region and below it, a tab control.

2) In your header, allow the user to specify which files to run.  This can be via textbox + browse, a list they can select, etc.  You can maintain the list via config file, or allow the user to add/create their own list.

3) When they launch an app, a tab is created with a text box in it.  Use Process.Start and redirect the standard output to the textbox.  An example of that is here.

4) Allow the users to close tabs (emulating the "close program" thing you're trying to do).

The nice thing about this approach is that the user could keep the window open as long as they like, even after a process is stopped.  They can also shut down all processes at the same time by closing the console window.  The processes could be in their own threads.

If you're looking to learn more about the .Net Framework, my above solution will take you on a pretty good ride.  You'll get to work through:

1) some threading bits

2) config files

3) dynamic control creation/removal

4) delegates - you'll need these to put the results of the sub-app output back on the UI thread

Sounds like an interesting project, Daniel.  Best of luck and hope this helps.

Cheers,

-jc

---

Me, coding and stuff: Mr. James

Answer 4

Please post code of what you have so far for a more exact answer.

Instead of sharing forms and their controls, define an object and share that.  Much easier.

You need to control instances of the application running, too.

---

Mark the best replies as answers. "Fooling computers since 1971."

Answer 5

Rudedog,

From reading Daniel's posts, it sounds more like he's looking for direction rather than specific code help.  If you read his post, he's also saying there could be any number of other applications that exist outside the app he's got.  While defining an object to share is a great pattern, it also doesn't sound like he's trying to talk between apps, only listen to the 'sub' apps.

Cheers,

-jc

---

Me, coding and stuff: Mr. James

Answer 6

Ever heard of the Observer Pattern?
That object would be the event publisher, observing the other applications.

---

Mark the best replies as answers. "Fooling computers since 1971."

Answer 7

Which, when launched externally, would attach how?

---

Me, coding and stuff: Mr. James

Answer 8

I asked the OP to post code for a more exact answer.
You can pass arguments to the process when you start it up.

Start(ProcessStartInfo)

Rudedog  =8^D

---

Mark the best replies as answers. "Fooling computers since 1971."

Answer 9

I asked the OP to post code for a more exact answer.
You can pass arguments to the process when you start it up.

Start(ProcessStartInfo)

Rudedog  =8^D

---

Mark the best replies as answers. "Fooling computers since 1971."

lol...D00D! are you reading my posts? heheh...

We're probably arguing the same points.  I don't see a constructor overload that would allow you to pass in an object...a lot of string, but no objects.

I'm a huge GOF fan and have used Observer for likely almost a decade (when I switched to OO) but I'm not sure I see the point in putting an academic-implementation of a pattern in place if all we're trying to do is listen to something that's already generating output.

hehe...by now we're waay off topic.  But nice to meet you, dog. ;o)

Daniel, care to interject on this thread that we decided to hijack?

-jc

---

Me, coding and stuff: Mr. James

Answer 10

James,
What you suggest here sounds like the best approach so far.  I threw around some ideas with a coworker and this is similar to what we came up with. 

That said, we probably will need to set up a windows service after all, mainly because the "sub apps" can be launched from any number of programs, not one central console.

The original idea (I do have some test code written) involved having each of the processes (app1.exe, app2.exe, etc...) "attach" themselves to a static/singleton sort of class, which would in turn create a form to display the output of whichever programs were currently "attached".  However, even attaching only a single application to this class proved problematic; so I figured I'd ask here before spinning my wheels a bunch more.


Thanks for the insight and ideas.  They have been helpful.

Thanks,
// Daniel