Single instance and showing a form

[=?Utf-8?B?TWF0dA==?=]

Hi

I have an app that runs without a main form, just a notification icon, when
the user clicks the icon the form is shown, and when the form is minimized
it's hidden.

This all works great, and I have implemented single instance so that when
another instance is run, an event gets signalled in the 1st instance, and
what I would like to do is to show the form. I can do this using Form.Invoke
to show the form in most cases, however at startup of my app the form isn't
shown and if the user runs the app again, I can't use Form.Invoke as there
isn't a valid window handle.

How can I call my code to show the form in the context of the UI thread? If
I call Form.Show from the thread that is waiting on the event (which is from
the threadpool) the form doesn't show properly and all hell breaks loose :)

Thanks in advance!

Matt

[Peter Duniho]

On Sun, 14 Sep 2008 02:03:01 -0700, Matt <Ma**@discussions.microsoft.com>
wrote:

[...]
How can I call my code to show the form in the context of the UI thread?
If
I call Form.Show from the thread that is waiting on the event (which is
from
the threadpool) the form doesn't show properly and all hell breaks loose
:)

There is a class call SynchronizationContext that you can use in lieu of a
Control instance for invoking a delegate on a particular thread. It's
possible that using that would address your need.

Alternatively, you could go ahead and create the form instance immediately
when your application starts, and then call Control.CreateHandle() in your
form's constructor to ensure that its window handle is created and that it
can receive messages (necessary for Invoke() to work). Then you have the
form instance available for calling Invoke(), even though it hasn't been
shown yet. I haven't had a chance to test that particular technique, but
I think it should work.

Finally, you might consider having your main thread not call
Application.Run() until you're ready to show the form for the first time.
Just have it wait (e.g. using an AutoResetEvent or with the Monitor
class), and then have logic in your window-showing code that, if the form
hasn't been created yet, signals the main thread to proceed with creating
and showing the form instance, and then calling Application.Run(). If the
form has been created, then of course you'd just show it. The former
wouldn't require calling Invoke() -- you'd just be using the inter-thread
communication object to release the main thread -- and of course the
latter can call Invoke() since you'd have created the form instance by
then.

Pete

[=?Utf-8?B?TWF0dA==?=]

Hi Pete

Thanks for the ideas, I had looked at SynchronizationContext briefly, but
every time i accessed SynchronizationContext.Current it always returned null,
although I was only doing this early on in the app before I had called
Application.Run, so that might have been the issue.

I had tried instantiating the MainForm object and then calling Create, but
that did not allow me to use Invoke, although I haven't tried using
CreateHandle, I'll give that a try later and look into the
SynchronizationContext in more detail as well. I can't try anything at the
moment as my development machine b0rked this morning :(

Also your comments about not calling Application.Run until I need to show
the form are interesting, hadn't thought of that one, thanks for pointing it
out! :) One question though, do I need to call Application.Run for the
notification icon to work? I'll give it a try and see what happens later,
when my machine is back up and running :)

Cheers

Matt

"Peter Duniho" wrote:

On Sun, 14 Sep 2008 02:03:01 -0700, Matt <Ma**@discussions.microsoft.com>
wrote:

[...]
How can I call my code to show the form in the context of the UI thread?
If
I call Form.Show from the thread that is waiting on the event (which is
from
the threadpool) the form doesn't show properly and all hell breaks loose
:)

There is a class call SynchronizationContext that you can use in lieu of a
Control instance for invoking a delegate on a particular thread. It's
possible that using that would address your need.

Alternatively, you could go ahead and create the form instance immediately
when your application starts, and then call Control.CreateHandle() in your
form's constructor to ensure that its window handle is created and that it
can receive messages (necessary for Invoke() to work). Then you have the
form instance available for calling Invoke(), even though it hasn't been
shown yet. I haven't had a chance to test that particular technique, but
I think it should work.

Finally, you might consider having your main thread not call
Application.Run() until you're ready to show the form for the first time.
Just have it wait (e.g. using an AutoResetEvent or with the Monitor
class), and then have logic in your window-showing code that, if the form
hasn't been created yet, signals the main thread to proceed with creating
and showing the form instance, and then calling Application.Run(). If the
form has been created, then of course you'd just show it. The former
wouldn't require calling Invoke() -- you'd just be using the inter-thread
communication object to release the main thread -- and of course the
latter can call Invoke() since you'd have created the form instance by
then.

Pete

[Peter Duniho]

On Sun, 14 Sep 2008 18:55:01 -0700, Matt <Ma**@discussions.microsoft.com>
wrote:

Hi Pete

Thanks for the ideas, I had looked at SynchronizationContext briefly, but
every time i accessed SynchronizationContext.Current it always returned
null,
although I was only doing this early on in the app before I had called
Application.Run, so that might have been the issue.

Hmmm...not sure. I admit, I've never had to use the class in a context
when I was trying to get the instance before I'd called
Application.Run(). I don't know why it shouldn't work before you called
Application.Run(), but that could simply be one of the dark corners of the
Forms API.

I suppose you might try just instantiating the class directly ("new
SynchronizationContext()") but I have low confidence that that would work
(I'd expect a Forms application to require an actual
WindowsFormsSynchronizationContext instance).

I had tried instantiating the MainForm object and then calling Create,
but
that did not allow me to use Invoke, although I haven't tried using
CreateHandle,

There's no "Create()" method. Maybe you mean CreateControl()? If so,
then yes...that behaves differently than CreateHandle(). In particular,
it won't do anything if the Visible property of the Control is false,
which it would be in this case.

CreateHandle(), on the other hand, will create the window handle for the
control, regardless of its current visibility state.

[...]
Also your comments about not calling Application.Run until I need to show
the form are interesting, hadn't thought of that one, thanks for
pointing it
out! :) One question though, do I need to call Application.Run for the
notification icon to work?

I don't know. It's not something I've had a need to try. I wouldn't
think you'd need to, but if you do need for Application.Run() to be called
before NotifyIcon to work, a variation on what I described would be to go
ahead and call Application.Run() during startup, without showing the
form. But use the Run(ApplicationContext) overload so that you can pass
in your own ApplicationContext instance that allows you to call ExitThread
on that instance.

That way, you can cause Application.Run() to exit, after which that thread
could then create the form instance, show it, and then call
Application.Run() again.

Now, all that said, I believe that putting a call to CreateHandle() into
your form constructor will allow you to call Invoke() on that form
instance without having actually shown it yet.

Barring that, I'd hope you could get the NotifyIcon to work without having
to actually call Application.Run(). After all, the NotifyIcon is running
on a different thread, and in fact that fact is the reason you're having
trouble in the first place. :)

And barring all that, you could use an explicit ApplicationContext so that
you can call Application.Run() and then control its execution from another
thread, so that you can force it to return allowing your code to then
create the form, show it, and then call Application.Run() again.

Especially once you get to that last approach, it's kind of a hack and I'd
hope that calling CreateHandle() would work instead. But if it doesn't,
these alternatives shouldn't be _too_ bad, I think.

Pete

[=?Utf-8?B?TWF0dA==?=]

Thanks again Pete for your help, I'll try out your ideas and let you know
about the Application.Run() with the NotifyIcon, I'm interested to know
myself.

You were correct, I did mean CreateControl, sorry, not having access to my
PC (lol, it won't even turn on, I'm waiting for an engineer to arrive) I
can't access the source code, it sounds like CreateHandle is what I need, so
I'll give that a try once my pc is back up and running.

And as far as using the application context, I have to agree with you, seems
like a bit of a hack and only to be used if all else fails :)

Thanks again for your help!

Matt

[=?Utf-8?B?TWF0dA==?=]

Hi Peter

I finally have got a development PC back up and running again, and have
given your ideas a try, and I'm happy to say that the Control.CreateHandle
idea has worked a treat! So now I have a nice single instance class that can
notify the running instance when it's run a second time and will show the
form correctly in all cases.

I took another look at the documentation, and according to that,
CreateControl is supposed to be the method to use, as it creates the handle
and also any child controls, but it definitely doesn't create the handle, oh
well :)

Many thanks for your suggestions!

Matt

[Peter Duniho]

On Mon, 22 Sep 2008 19:56:00 -0700, Matt <Ma**@discussions.microsoft.com>
wrote:

Hi Peter

I finally have got a development PC back up and running again, and have
given your ideas a try, and I'm happy to say that the
Control.CreateHandle
idea has worked a treat! So now I have a nice single instance class that
can
notify the running instance when it's run a second time and will show the
form correctly in all cases.

Excellent. Glad to hear it worked for you.

I took another look at the documentation, and according to that,
CreateControl is supposed to be the method to use, as it creates the
handle
and also any child controls, but it definitely doesn't create the
handle, oh
well :)

I'm not sure what docs you're looking at, but the MSDN docs do clearly
state that CreateControl() will _not_ create the handle if the Visible
property is "false". And of course, until you have shown the form, it
will be "false". Since your scenario is one in which the form has
specifically not been shown, thus ensuring that the Visible property is
"false", the docs do clearly indicate that in your scenario, calling
CreateControl() isn't going to have any effect.

Pete

[=?Utf-8?B?TWF0dA==?=]

Yeah it was the docs for Control.CreateHandle... it says you should use
CreateControl as the preferred method, which was why I tried CreateControl
originally, but I did miss the part about the visible flag in the docs for
CreateControl... Doh! Sorry about that

Thanks again

Matt

"Peter Duniho" wrote:

On Mon, 22 Sep 2008 19:56:00 -0700, Matt <Ma**@discussions.microsoft.com>
wrote:

Hi Peter

I finally have got a development PC back up and running again, and have
given your ideas a try, and I'm happy to say that the
Control.CreateHandle
idea has worked a treat! So now I have a nice single instance class that
can
notify the running instance when it's run a second time and will show the
form correctly in all cases.

Excellent. Glad to hear it worked for you.

I took another look at the documentation, and according to that,
CreateControl is supposed to be the method to use, as it creates the
handle
and also any child controls, but it definitely doesn't create the
handle, oh
well :)

I'm not sure what docs you're looking at, but the MSDN docs do clearly
state that CreateControl() will _not_ create the handle if the Visible
property is "false". And of course, until you have shown the form, it
will be "false". Since your scenario is one in which the form has
specifically not been shown, thus ensuring that the Visible property is
"false", the docs do clearly indicate that in your scenario, calling
CreateControl() isn't going to have any effect.

Pete