Here's an interesting one...

[Terry Olsen]

I have a program that seems to be locked up when it's chugging away. It
takes about 2-3 hours for its process to complete and normally runs between
2am-5am when nobody is in the office so it's not really a big deal. But
i've noticed that if a user was to click on the CloseBox, the Windows "This
Program is not responding" dialog pops up and gives the user the option to
stop the program. Is there a way to stop this from happening? I would
assume that if the program was really hung then I could ctrl-alt-delete it
and stop it that way...

 

[Jeff Johnson]

I have a program that seems to be locked up when it's chugging away. It
takes about 2-3 hours for its process to complete and normally runs between
2am-5am when nobody is in the office so it's not really a big deal. But
i've noticed that if a user was to click on the CloseBox, the Windows "This
Program is not responding" dialog pops up and gives the user the option to
stop the program. Is there a way to stop this from happening?

You could put DoEvents in your program every few seconds or every x
iterations of a loop, or you could put the long-running process in a
separate thread (recommended). But unless you find some method of allowing
the UI to respond to external events (like a mouse click) there's no way to
prevent Window from doing the Not Responding thing.

 

[Bernie Yaeger]

Hi Terry,

Jeff's correct, but you can 'disable' the close (X) option on the window.
Here's how:
set up a boolean at the class level
dim closetest as boolean = true

In the form's closing event:
If closetest = True Then

e.Cancel = True

End If

Only chane closetest to false when a 'close' button is clicked, if you want
that.

HTH,

Bernie Yaeger

 

[Terry Olsen]

Yeah...I didn't think it mattered too much since I don't want anyone messing
with it anyway. I have the e.cancel = true during the process so I thought
that would stop anyone from shutting down the app...but then I noticed the
"Not Responding" anomoly...now I gotta go learn how to do threads...

"If it's not one thing, it's another. Either you can't get a job in
journalism, or Walter Cronkite thinks you cut the cheese in his
office." --Rosanne Rosannadanna

 

[Ray Cassick \(Home\)]

Threads are not that heard. There are many decent examples on the web about
them.

 

[Jeff Johnson [MVP:VB]]

Jeff's correct, but you can 'disable' the close (X) option on the window.
Here's how:
set up a boolean at the class level
dim closetest as boolean = true

In the form's closing event:
If closetest = True Then

e.Cancel = True

End If

Only chane closetest to false when a 'close' button is clicked, if you
want
that.

I don't see what good that will do. The problem is that the program is in a
long-running process and therefore isn't checking its message queue.
Therefore, the form's Close event won't be entered and your code will never
run. You've got to do something to yield to the CPU. Correct me if I'm
wrong....

 

[Jay B. Harlow [MVP - Outlook]]

Terry,
For an application that takes 2 to 3 hours without any user intervention, I
would consider creating a Console Application or a Windows Service instead
of a Windows Forms application!

A Windows Service by definition runs in the background so there is no UI
needed (or allowed) Windows Service doesn't even require a person logged
into the machine.

A Console Application runs in a console window (aka a "DOS Box").

I would consider using Performance Counters and/or an Event Log so my
"Process" (Windows Service or Console Application) could notify any user of
its progress. I might create a Windows Forms application that read these
Performance Counters and/or Event Logs & displayed the info in a "usable"
format, possible on remote machines! For a Console Application I would
consider simply using Console.Write to display progress messages to the
user.

The "This Program is not responding" is caused because your app did not
respond to any windows messages (Mouse Move) in a timely manner. This is
normally an indication of a hung app. DoEvents is one method of responding
to these windows messages in a timely manner. Threads is another. Both
require "special" code as your are mixing your "process" with the "UI". As
I suggested above I would literally separate the "process" from the "UI" by
making two programs...

Hope this helps
Jay