Long Process

[John Wright]

I have a long process I run that needs to be complete before the user can continue. I can change the cursor to an hourglass, but I want to update the Status Strip on the bottom during the process. I set the statusstrip label to "Downloading... ", but it will not show up on the form. I need to display this message before it starts the process. I can put a thread.sleep for 1 second after I do the initial process, but that seems sloppy to me. Any suggestions? Here is my code launched from a button click:
'update the label--This does not show because the process starts before the UI updates
slDBList.Text = "Retrieving Databases..."Tr yMe.Cursor = Cursors.WaitCur sorDim lstServers As List(Of String)'set to false in case of an error boolServersLoad ed = FalseboolDBLoad ed = False'clear the servers list cbServers.DataS ource = Nothing'clear the databases list dbDatabases.Dat aSource = NothingIf chkSort.Checked = True ThenlstServers = GetSqlServers(T rue)ElselstServ ers = GetSqlServers(F alse)End IfcbServers.Dat aSource = lstServers'set to true to enabled the selected index change on the dropdown boolServersLoad ed = TrueslDBList.Te xt = ""Catch ex As ExceptionMessag eBox.Show("Erro r loading server list. Error: " & ex.ToString, "Data Error", MessageBoxButto ns.OK, MessageBoxIcon. Error)boolServe rsLoaded = FalseslDBList.T ext = ""FinallyMe.Cur sor = Cursors.ArrowEn d Try

[Armin Zingler]

"Joergen Bech @ post1.tele.dk>" <jbech<NOSPAMNO SPAMschrieb

>>(But I see it as your agreement supplemented by the BGW)

I'll pretend that additional information was my excuse for
posting it and saves some face.

No problem. Everything's fine. Even the whether. :)
Armin

[Armin Zingler]

No problem. Everything's fine. Even the whether. :)

"whether".Repla ce("whether", "weather")

;-)

[Stephany Young]

Whether or not the wether has been out in the weather, it will still be just
fine with mint sauce.

Figure that one out :)
"Armin Zingler" <az*******@free net.dewrote in message
news:%2******** *******@TK2MSFT NGP06.phx.gbl.. .

>No problem. Everything's fine. Even the whether. :)

"whether".Repla ce("whether", "weather")

;-)

[Cor Ligthert[MVP]]

Yes

"Armin Zingler" <az*******@free net.deschreef in bericht
news:%2******** **********@TK2M SFTNGP06.phx.gb l...

"Cor Ligthert[MVP]" <no************ @planet.nlschri eb

>Joergen,

Be aware that you never should do what you advice as it is a
critical process that has to be completed, and the user can end that
in the middle without knowing what is the effect.

Think by instance in a paying process by banks, were steps have to
be done, I would never be the one who would give an advice as yours.

Just my idea,

Cor

Like Joergen, I don't understand this plea. Using another thread to avoid
the UI thread being blocked is the (only) right action, IMO. But maybe you
meant that the UI thread also have to be in an appropriate state depending
on the whole situation, where I would agree.
Armin

[Just_a_fan]

If DoEvents should not be used any more, why is it in the language?

application.doe vents

That's the quickest way to get a control updated. Works just fine. This
is the first I have heard about it not being valid any longer. Does
Microsoft know about this?

Mike

On Thu, 22 May 2008 11:09:12 +0200, in
microsoft.publi c.dotnet.langua ges.vb "Armin Zingler"
<az*******@free net.dewrote:

>"Mayur H Chauhan" <ma***@orioninc .comschrieb

>How about Application.DoE vents ? This might help for processing
pending thread.

Doevents should not be used anymore. It was valid with previous VB
versions where multi threading was (appart from appartment threading)
almost impossible. Doevents creates more problems than necessary. First,
the classification of UI tasks and independent other tasks would have to
be removed. Not every task has an abstract and regular event/callback
mechanism that can be used to update the UI, especially when talking
about long running database activities. In addition, you'd have
to be aware of code reentrance. Moreover, why create new code to process
messages even if there is already a message loop that is made for it? My
experience is that almost every time when I was using Doevents, 5 LOC
later I'd wished to go the "clean" way and had used a separate thread
instead.
Armin

[Joergen Bech]

There are many language features coming from VB6 that have found
a new home at the core of the framework because that is where they
belong rather than just in the Microsoft.Visua lBasic namespace.

Leaving it out would mean one more thing preventing many VB6
applications from being ported to .Net.

What DoEvents does could be achieved with other languages
as well - including non-Microsoft languages before .Net.

It is still a bad practice for all the reasons discussed in this
thread (and more).

If you, say, google for discussions about how to accomplish the
same thing in Java, the discussions usually go along this line:

- a) Is there something similar to DoEvents in Java?
- b) What the heck is DoEvents and why do you need it?
- a) (explains)
- b) Don't do that. Do it this way ...

Regards,

Joergen Bech

On Thu, 22 May 2008 21:29:55 -0700, Ju********@home .net wrote:

>If DoEvents should not be used any more, why is it in the language?

application.do events

That's the quickest way to get a control updated. Works just fine. This
is the first I have heard about it not being valid any longer. Does
Microsoft know about this?

Mike

On Thu, 22 May 2008 11:09:12 +0200, in
microsoft.publ ic.dotnet.langu ages.vb "Armin Zingler"
<az*******@fre enet.dewrote:

>>"Mayur H Chauhan" <ma***@orioninc .comschrieb

>>How about Application.DoE vents ? This might help for processing
pending thread.

Doevents should not be used anymore. It was valid with previous VB
versions where multi threading was (appart from appartment threading)
almost impossible. Doevents creates more problems than necessary. First,
the classification of UI tasks and independent other tasks would have to
be removed. Not every task has an abstract and regular event/callback
mechanism that can be used to update the UI, especially when talking
about long running database activities. In addition, you'd have
to be aware of code reentrance. Moreover, why create new code to process
messages even if there is already a message loop that is made for it? My
experience is that almost every time when I was using Doevents, 5 LOC
later I'd wished to go the "clean" way and had used a separate thread
instead.
Armin

[Armin Zingler]

<Ju********@hom e.netschrieb

If DoEvents should not be used any more, why is it in the language?

I should have added that is only my opinion. However, not only mine.
(does this make sense?)

From an objective point of view, DoEvents is not an evil thing. However,
be very careful using it, and live with the drawbacks mentioned. After
writing dozends of paragraphs, assuming that DoEvents is, as you write,
is "in the language", I remember that it isn't because it's not in the
MSVB namespace. Therefore, long story short:

- Thinking in VB6 times usually didn't include the opportunity of
multiple threads. (again, appartment threading left out). Therefore,
DoEvents was the solution for what it does.

- Thinking now, my brain works this way: I have to put a task anywhere
in the code. Every task is executed in a thread. I wonder: In which
thread do I want to execute it? Well, I have a UI thread, but as I want
it to talk to the user and accept it's input, I don't recognize this
thread as the right one to put my task in. I decide to put it into a new
thread. So, I never come to the point that forces me to use DoEvents.
The different way of thinking because of taking into account free
threading as a matter of course (right words?), causes that I do not
have to use DoEvents anymore. Managing tasks and threads got a very high
priority now. As a consequence, I call DoEvents obsolete.

application.doe vents

That's the quickest way to get a control updated. Works just fine.

That was even the wrong way in VB6. Also often written in the VB6 groups
in the past. To update a control, call it's Refresh method. DoEvents
processes *all* messages in the message queue. So, to process one
message, process all messages? Naah. In 90% (no, I didn't count) people
weren't aware of the fact that, e.g., the user will be able to press
Alt+F4 to close the Form while using Doevents. Usually the app crashes
then. (I don't say that using multiple threads is easier to handle.)

This is the first I have heard about it not being valid any longer.
Does Microsoft know about this?

I haven't met him yet. ;-)
Armin

[Armin Zingler]

One main thing I forgot:
Imagine you put the work in the UI thread and use Doevents. Everything
works fine. Now you want to do an additional job at the same time. How
will you handle all this in the UI thread? How can you switch between
the three tasks (UI, job 1, job 2) all within the same thread?

Maybe you say: Then it's time for another thread. I'd answer: Which of
the jobs (job1 or job2) runs in the UI thread and which one in a
separate thread? I guess you wouldn't have an answer. Therefore I always
suggest: Have the UI thread only do the things that it's name says. (I
personally accept an unresponsive UI only for few seconds, apart from
heavy and unavoidable UI updates (and apart from some tools I wrote for
my own joy only))
Armin

[Armin Zingler]

Sorry, me again... :-(

Could have been written so basic and simple:
If I have to do two things at the same time, I put them into separate
threads instead of alternately doing them in the same thread. Therefore,
no doevents required.

[Steve Gerrard]

Armin Zingler wrote:

<Ju********@hom e.netschrieb

From an objective point of view, DoEvents is not an evil thing.

DoEvents processes *all* messages in the message queue.

There was one good use of DoEvents, as I remember. You could disable a form, or
a toolbar, or what have you. Then at the end of a long process, call DoEvents.
This would clear out all the clicks the user had made, without calling any click
event handlers. Then you would re-enable the form or controls. It worked well to
avoid starting something from a click the user made a while ago.