Display the main window for another program

[Bob Altman]

Hi all,

This is such a common scenario that I'm sure there must be some magic buried
in .Net to accomplish it... I have a program that wants to first check to
see if another instance of the same program is already running; if so, it
wants to ensure that the main window of the other instance displayed.

I can use a Mutex to detect the presence of another instance of the program,
but I can't find an easy way to set the other instance's main window state
to "normal" and bring it to the top of the Z order. Any suggestions?

 

[Herfried K. Wagner [MVP]]

I can use a Mutex to detect the presence of another instance of the
program, but I can't find an easy way to set the other instance's main
window state to "normal" and bring it to the top of the Z order. Any
suggestions?

Determine the other instance's 'Process' object and use
'SetForegroundWindow' (p/invoke) to bring the other instance's main window
'MainWindowHandle' to front. You can change a window's state using the
'ShowWindow' function (p/invoke).

 

[Bob Altman]

That's pretty much what I'm doing. I was hoping to find some of this magic
baked into the CLR.

The basic problem with this approach is the "determine the other instance's
'Process' object" step. If several instances of my app are starting up more
or less at the same time, there's no obvious (to me) way to determine which
instance holds the "I'm the primary instance" mutex.

One way to solve this issue is to have the app expose an interface as a
well-known singleton via remoting after it acquires the mutex. If an
instance of the app fails to acquire the mutex then it gets a reference to
the singleton and calls a method on the interface that causes the primary
instance of the app to restore its own Window state and bring itself to the
front of the Z order. The obvious downside to this approach is that I need
to write more than a few lines of code to declare the interface, expose it
via remoting, try to call the remoted interface, handle exceptions in case
the primary instance has acquired the mutex but hasn't yet completed setting
up the remoted singleton, etc.

Maybe there is some easier way for the primary instance of the app to
publish its Window handle via some sort of shared resource (shared memory,
an environment variable, etc.) so that subsequent instances can easily get
it and use it to call BringWindowToTop. In that case, I'd need to use a
named event to indicate when the shared resource is available (to close the
timing hole where a second instance of the app tries to access the shared
resource before the primary instance has set it up). Unfortunately, the
Event class doesn't seem to support named events for some strange reason.

Sigh...

 

[stand__sure]

there are a few ways to cheat this... (none are pretty, but they should
work) -- I'm not keen on the remoting object notion and would prefer
seeing a pooled COM component if you really must do this... however, I
think that these approaches are a bit too "expensive"...

alternatives:
a) you could have your initial app set a registry value with the PID
and successive apps check this value when they fail to create the mutex
b) use the new Semaphore class (in 2.0) and set the min/max value equal
to the PID -- if the duplicate mutex creation fails, then check the
semaphore count