Prev: how to wait for data from the serial port
Next: Problem with the Soft Input Panel (SIP)
From: Scott Gifford on 22 Jun 2008 18:21
Hello,

In my Main() method in Program.cs, I have an exception handler around
my Application.Run(). If I catch an exception, I would like to bring
up a dialog box asking the user if they would like to send an error
report.

In my first attempt, I created the form for the dialog box, then tried
to restart the message loop with another call to Application.Run().
Unfortunately, this call to Appliction.Run() immediately throws an
exception. The documentation says that this will happen if I try to
start a message loop on a thread that is already running a message
loop, and Application.Run() seems to think the message loop is still
running. Perhaps this is because it was exited abnormally via an
exception.

In my second attempt, I starting a new thread, and called
Application.Run() from there. This works, but adds a lot of clutter
to an otherwise straightforward piece of code, and seems a bit kludgey
besides.

Is there a better way to do this?

Thanks!

----Scott.
From: Chris Tacke, MVP on 22 Jun 2008 23:37
It seems to me that if you end up in a handler back around run, then it's
uncaught elsewhere and state is pretty much undefined at that point. If it
were me, I'd actually let the process die and relaunch - just do a
Process.Create in the handler and re-launch. Anything else is asking for
trouble.

-Chris

"Scott Gifford" <sgifford(a)suspectclass.com> wrote in message
news:ly3an5qffb.fsf(a)gfn.org...
> Hello,
>
> In my Main() method in Program.cs, I have an exception handler around
> my Application.Run(). If I catch an exception, I would like to bring
> up a dialog box asking the user if they would like to send an error
> report.
>
> In my first attempt, I created the form for the dialog box, then tried
> to restart the message loop with another call to Application.Run().
> Unfortunately, this call to Appliction.Run() immediately throws an
> exception. The documentation says that this will happen if I try to
> start a message loop on a thread that is already running a message
> loop, and Application.Run() seems to think the message loop is still
> running. Perhaps this is because it was exited abnormally via an
> exception.
>
> In my second attempt, I starting a new thread, and called
> Application.Run() from there. This works, but adds a lot of clutter
> to an otherwise straightforward piece of code, and seems a bit kludgey
> besides.
>
> Is there a better way to do this?
>
> Thanks!
>
> ----Scott.

From: Scott Gifford on 24 Jun 2008 10:39
"Chris Tacke, MVP" <ctacke.at.opennetcf.dot.com> writes:

> It seems to me that if you end up in a handler back around run, then
> it's uncaught elsewhere and state is pretty much undefined at that
> point. If it were me, I'd actually let the process die and relaunch -
> just do a Process.Create in the handler and re-launch. Anything else
> is asking for trouble.

Thanks, Chris. You're right, the application state is undefined, but
the log upload window ignores the previous state, and just uses things
that are under its control: objects it creates or a few static
properties. Since it's running in a new message loop I don't see much
risk of the corrupted state from the previous window causing problems,
but perhaps there's something I'm missing.

I have a few pieces of state that come from the application that I'd
like to pass along to the log upload window, which makes using
CreateProcess a bit tricky; I would have to put them all on the
command line, taking care to escape everything properly so it doesn't
launch something I don't expect, then unescape them when parsing the
command line. All do-able, but a bit of a hassle, and somewhat
error-prone, with possible security risks if I get it wrong.

-----Scott.


> "Scott Gifford" <sgifford(a)suspectclass.com> wrote in message
> news:ly3an5qffb.fsf(a)gfn.org...
>> Hello,
>>
>> In my Main() method in Program.cs, I have an exception handler around
>> my Application.Run(). If I catch an exception, I would like to bring
>> up a dialog box asking the user if they would like to send an error
>> report.
>>
>> In my first attempt, I created the form for the dialog box, then tried
>> to restart the message loop with another call to Application.Run().
>> Unfortunately, this call to Appliction.Run() immediately throws an
>> exception. The documentation says that this will happen if I try to
>> start a message loop on a thread that is already running a message
>> loop, and Application.Run() seems to think the message loop is still
>> running. Perhaps this is because it was exited abnormally via an
>> exception.
>>
>> In my second attempt, I starting a new thread, and called
>> Application.Run() from there. This works, but adds a lot of clutter
>> to an otherwise straightforward piece of code, and seems a bit kludgey
>> besides.
>>
>> Is there a better way to do this?
>>
>> Thanks!
>>
>> ----Scott.
From: Chris Tacke, MVP on 24 Jun 2008 11:13
I'd be inclined to dump out a "state file" instead of using the command
line. I'm certain you could get another message pump running - it might
require some hacky waiting for the current pump thread to die or just using
something like OpenNETCF's Application2.Run to create your own pump (because
it doesn't check for multiple pumps). Still, my gut tells me that that
second pump is going to lead to some weird headache down the road and it
will manifest itself in some weird way that sucks up a week of beating your
head on the desk. I'd just dump whatever state you want saved to a file,
re-aluch, and load it back up. There are lots of ways to do that - a
personal favorite is the AppSettings stuff we added to the SDF in the last
version, but I'm a bit biased. I did, however, write it for almost this
exact type of use - for persisting application state across runs.

-Chris


"Scott Gifford" <sgifford(a)suspectclass.com> wrote in message
news:lywskekid1.fsf(a)gfn.org...
> "Chris Tacke, MVP" <ctacke.at.opennetcf.dot.com> writes:
>
>> It seems to me that if you end up in a handler back around run, then
>> it's uncaught elsewhere and state is pretty much undefined at that
>> point. If it were me, I'd actually let the process die and relaunch -
>> just do a Process.Create in the handler and re-launch. Anything else
>> is asking for trouble.
>
> Thanks, Chris. You're right, the application state is undefined, but
> the log upload window ignores the previous state, and just uses things
> that are under its control: objects it creates or a few static
> properties. Since it's running in a new message loop I don't see much
> risk of the corrupted state from the previous window causing problems,
> but perhaps there's something I'm missing.
>
> I have a few pieces of state that come from the application that I'd
> like to pass along to the log upload window, which makes using
> CreateProcess a bit tricky; I would have to put them all on the
> command line, taking care to escape everything properly so it doesn't
> launch something I don't expect, then unescape them when parsing the
> command line. All do-able, but a bit of a hassle, and somewhat
> error-prone, with possible security risks if I get it wrong.
>
> -----Scott.
>
>
>> "Scott Gifford" <sgifford(a)suspectclass.com> wrote in message
>> news:ly3an5qffb.fsf(a)gfn.org...
>>> Hello,
>>>
>>> In my Main() method in Program.cs, I have an exception handler around
>>> my Application.Run(). If I catch an exception, I would like to bring
>>> up a dialog box asking the user if they would like to send an error
>>> report.
>>>
>>> In my first attempt, I created the form for the dialog box, then tried
>>> to restart the message loop with another call to Application.Run().
>>> Unfortunately, this call to Appliction.Run() immediately throws an
>>> exception. The documentation says that this will happen if I try to
>>> start a message loop on a thread that is already running a message
>>> loop, and Application.Run() seems to think the message loop is still
>>> running. Perhaps this is because it was exited abnormally via an
>>> exception.
>>>
>>> In my second attempt, I starting a new thread, and called
>>> Application.Run() from there. This works, but adds a lot of clutter
>>> to an otherwise straightforward piece of code, and seems a bit kludgey
>>> besides.
>>>
>>> Is there a better way to do this?
>>>
>>> Thanks!
>>>
>>> ----Scott.

From: Scott Gifford on 24 Jun 2008 12:40
"Chris Tacke, MVP" <ctacke.at.opennetcf.dot.com> writes:

> I'd be inclined to dump out a "state file" instead of using the
> command line.

Yeah, that's a good idea, I should be able to do that from the
exception handler without needing a new message loop.

> I'm certain you could get another message pump running - it might
> require some hacky waiting for the current pump thread to die or
> just using something like OpenNETCF's Application2.Run to create
> your own pump (because it doesn't check for multiple pumps).

I just created a new thread and ran the message pump there, then had
the first thread Join the new thread. It was straightforward enough,
but yeah, a little hacky.

> Still, my gut tells me that that second pump is going to lead to
> some weird headache down the road and it will manifest itself in
> some weird way that sucks up a week of beating your head on the
> desk.

:-) Thanks, I'm sure that by now your gut must be well-tuned to these
sorts of things.

---Scott.
 |  Next  |  Last
Pages: 1 2
Prev: how to wait for data from the serial port
Next: Problem with the Soft Input Panel (SIP)