Mysteriously invincible process

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

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?
 
Patty O'Dors said:
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?
Click to expand...

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.
 
Hi,

I think this is what is happening,

Maybe with process explorer from sysinternals.com 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=en&lr=&ie=UTF-8&selm=O9yxWGYiBHA.1960@tkmsftngp04&rnum=4


Cheers,

--
Ignacio Machin,
ignacio.machin AT dot.state.fl.us
Florida Department Of Transportation
 
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 said:
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....
Click to expand...

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
ThreadAbortException whenever the form closes?
Click to expand...

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.
 
I suggest you break into the debugger and see what threads are around
to check it out.
Click to expand...

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.
No - if it's creating a new thread now, I would be very surprised if it
didn't create the thread regardless.
Click to expand...

From the threads window it would seem that no part of the saving process is
creating any other threads.
 
Patty O'Dors said:
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.


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

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