Mysteriously invincible process

[Patty O'Dors]

I've got a program that contains a crystal report, and it has a function that
saves off one report for each branch of the company, in a loop.
This all works beautifully, however - if the user closes the form while the
saving is taking place (it does take quite a long time) then it mysteriously
CARRIES ON saving the PDFs! The process is still there, just the form is
invisible.
I tried setting a flag to true and calling Dispose on the actual crystal
report ReportDocument object, both of which happen without error, and
although now it stops saving as the flag causes the loop to exit, the process
doesn't die.

Does anybody know of any way to determine what's keeping it alive?

[Jon Skeet [C# MVP]]

Patty O'Dors <Pa********@dis cussions.micros oft.com> wrote:

I've got a program that contains a crystal report, and it has a function that
saves off one report for each branch of the company, in a loop.
This all works beautifully, however - if the user closes the form while the
saving is taking place (it does take quite a long time) then it mysteriously
CARRIES ON saving the PDFs! The process is still there, just the form is
invisible.
I tried setting a flag to true and calling Dispose on the actual crystal
report ReportDocument object, both of which happen without error, and
although now it stops saving as the flag causes the loop to exit, the process
doesn't die.

Does anybody know of any way to determine what's keeping it alive?

Is it saving the PDFs in another thread? If so, that's probably what's
keeping it alive. The process stays alive until all non-background
threads have terminated.

--
Jon Skeet - <sk***@pobox.co m>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

[Ignacio Machin \( .NET/ C# MVP \)]

Hi,

I think this is what is happening,

Maybe with process explorer from sysinternals.co m you can see it.

In any case I think that if this process is going to be so time consuming
that the user may get bored and close the program before it ends you should
try another thing, like scheduling a job to be run in the background or
later, most of the time probably the user that start the process does not
care about the reports in the first time :)

Take a look at this post from Willy
http://groups.google.com/groups?hl=e...ftngp04&rnum=4
Cheers,

--
Ignacio Machin,
ignacio.machin AT dot.state.fl.us
Florida Department Of Transportation

"Jon Skeet [C# MVP]" <sk***@pobox.co m> wrote in message
news:MP******** *************** @msnews.microso ft.com...

Patty O'Dors <Pa********@dis cussions.micros oft.com> wrote:

I've got a program that contains a crystal report, and it has a function that saves off one report for each branch of the company, in a loop.
This all works beautifully, however - if the user closes the form while the saving is taking place (it does take quite a long time) then it mysteriously CARRIES ON saving the PDFs! The process is still there, just the form is
invisible.
I tried setting a flag to true and calling Dispose on the actual crystal
report ReportDocument object, both of which happen without error, and
although now it stops saving as the flag causes the loop to exit, the process doesn't die.

Does anybody know of any way to determine what's keeping it alive?

Is it saving the PDFs in another thread? If so, that's probably what's
keeping it alive. The process stays alive until all non-background
threads have terminated.

--
Jon Skeet - <sk***@pobox.co m>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

[Ignacio Machin \( .NET/ C# MVP \)]

Hi Patty,

It should be running on another thread, if it were running on the main
thread ( UI thread ) the interface will lock.

Again, I think that you should consider a non visible method for this,
either a scheduled job or even using MSMQ

Cheers,

--
Ignacio Machin,
ignacio.machin AT dot.state.fl.us
Florida Department Of Transportation
"Patty O'Dors" <Pa********@dis cussions.micros oft.com> wrote in message
news:18******** *************** ***********@mic rosoft.com...

No! It's not. It's right in the button's auto-generated handler.
"Jon Skeet [C# MVP]" wrote:

Patty O'Dors <Pa********@dis cussions.micros oft.com> wrote:

I've got a program that contains a crystal report, and it has a function that saves off one report for each branch of the company, in a loop.
This all works beautifully, however - if the user closes the form while the saving is taking place (it does take quite a long time) then it mysteriously CARRIES ON saving the PDFs! The process is still there, just the form is invisible.
I tried setting a flag to true and calling Dispose on the actual crystal report ReportDocument object, both of which happen without error, and
although now it stops saving as the flag causes the loop to exit, the process doesn't die.

Does anybody know of any way to determine what's keeping it alive?

Is it saving the PDFs in another thread? If so, that's probably what's
keeping it alive. The process stays alive until all non-background
threads have terminated.

--
Jon Skeet - <sk***@pobox.co m>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

[Jon Skeet [C# MVP]]

Patty O'Dors <Pa********@dis cussions.micros oft.com> wrote:

It should be running on another thread, if it were running on the main
thread ( UI thread ) the interface will lock.
The interface doesn't lock - it stays responsive as if I have put it in
another thread, but I'm telling you I haven't.

I can only assume that this is because, although I haven't multithreaded
myself, the method ExportToDisk of the crystal report uses another thread
itself and it is probably this that takes 99% of the time of the loop. It
definitely does seem weird....

I suggest you break into the debugger and see what threads are around
to check it out.
Is what you're saying that if I DO put it in another thread, then it will be
easier to kill it - as I will have an explicit object reference to the thread
that's doing the work, and I will just be able to give it a
ThreadAbortExce ption whenever the form closes?

No - if it's creating a new thread now, I would be very surprised if it
didn't create the thread regardless.

Is there no documented way of waiting until it's finished? If there
was, you could wait for each individual PDF to finish, testing a flag
between each file.

--
Jon Skeet - <sk***@pobox.co m>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

[Patty O'Dors]

I suggest you break into the debugger and see what threads are around
to check it out.
There's three - one that's listed as being in the button handler function
and two that just have no name. But there are the same three wherever I break
into the program.

Is what you're saying that if I DO put it in another thread, then it will be
easier to kill it - as I will have an explicit object reference to the thread
that's doing the work, and I will just be able to give it a
ThreadAbortExce ption whenever the form closes?
No - if it's creating a new thread now, I would be very surprised if it
didn't create the thread regardless.

From the threads window it would seem that no part of the saving process is
creating any other threads.

Is there no documented way of waiting until it's finished? If there
was, you could wait for each individual PDF to finish, testing a flag
between each file.

--
Jon Skeet - <sk***@pobox.co m>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

[Jon Skeet [C# MVP]]

Patty O'Dors <Pa********@dis cussions.micros oft.com> wrote:

I suggest you break into the debugger and see what threads are around
to check it out.

There's three - one that's listed as being in the button handler function
and two that just have no name. But there are the same three wherever I break
into the program.

Hmm.

Is what you're saying that if I DO put it in another thread, then
it will be easier to kill it - as I will have an explicit object
reference to the thread that's doing the work, and I will just be
able to give it a ThreadAbortExce ption whenever the form closes?

No - if it's creating a new thread now, I would be very surprised if it
didn't create the thread regardless.

From the threads window it would seem that no part of the saving process is
creating any other threads.

Hmm. That sounds extremely odd then. Perhaps it's creating other native
threads, and VS.NET doesn't show them? (Not sure.)

--
Jon Skeet - <sk***@pobox.co m>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too