1

What I thought would be pretty easy is quickly defeating me. I'm not a native C# programmer, but was asked to create a WinForm application that has a single instance. I''ve seen the Mutex examples already on StackOverflow, but the one thing that eludes me is the ability to pass parameters to window on the command line, parse the values and repaint the form with the new values.

Anyone have an example of this? The main thing that seems to be tripping me up is the threading. I want to run my.exe and show the window. Each time the form is run, I don't want a new form -- just to get the new parameters and show them in the form.

Any/All replies are appreciated!

Griff
  • 1,796
  • 3
  • 23
  • 48
  • Please put some more detail. For example about how you call you windows etc. – Preet Sangha Oct 16 '12 at 21:55
  • 2
    http://www.hanselman.com/blog/TheWeeklySourceCode31SingleInstanceWinFormsAndMicrosoftVisualBasicdll.aspx – Hans Passant Oct 16 '12 at 22:12
  • @HansPassant's suggestion +1 IMHO this should have been posted as an answer and be the voted one =) –  Oct 16 '12 at 22:59
  • I love this site! Hans, I wish you would have submitted this as an answer instead of a comment because you solved my problem. – Griff Oct 18 '12 at 00:07

2 Answers2

1

When you starting another instance of your application, you are running same code, but on different process. So, you need to look on passing data between processes. Something like Named Pipes or Remoting.

Community
  • 1
  • 1
Sergey Berezovskiy
  • 232,247
  • 41
  • 429
  • 459
  • My first reaction was to use a broker like RabbitMQ, but the project was bid very low and it was my first foray into C# programming. The comment left by Hans Passant was what I ended up doing. Thanks for the reply! – Griff Oct 18 '12 at 00:08
  • Didn't know about `WindowsFormsApplicationBase` in VB - very simple solution. But still same - it uses Remoting, as I suggested to do – Sergey Berezovskiy Oct 18 '12 at 06:09
0

@lazyberezovsky is right. Invoking again the application from the command line will spawn a different, unrelated process and you would require inter-process communication to forward the new parameters to the previously running app instance, before quitting the new process being invoked.

IMHO, the easiest way (not the best certainly) to communicate between these two processes would be using the Windows Registry, as this is already thread-safe and the API is very simple.

First, when the application runs, before showing the main form, I would perform a check to see if another instance of the app is running.

If false, it is the first time the app runs and I would process the command line and show the form as regular. I would also clear the registry key used for inter-process communication (see below).

If true, then I would store the command line in the registry on a specific key that will serve for inter-process communication and then I would terminate the application without even showing the main form.

Your running application (the first instance) will require to start a polling mechanism (could be a Windows timer firing once each second) that regularly examines the registry key where a new command line is expected . It would normally find and empty string and do nothing, but if the retrieved value is not empty, then it would mean the user spawned again the application with a different set of parameters, then you can proceed to decode your command line and repaint the window as necessary. After this, make sure you clear the registry entry again, so the polling mechanism resumes and detects the next time the application is invoked by the user.

Named pipes, WCF, .remoting or TCP sockets are IPC mechanisms that can be used and won't require a polling mechanism, that may be frowned upon by some. ;)

Hope this helps!

Community
  • 1
  • 1
  • 1
    The link submitted by @HansPassant refers to a much better (cleaner) solution than my alternative. Please take a look at it. =) –  Oct 16 '12 at 22:53