Long Process

  • Thread starter Thread starter John Wright
  • Start date Start date
Joergen Bech @ post1.tele.dk> said:
I'll pretend that additional information was my excuse for
posting it and saves some face.
Click to expand...

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


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

"whether".Replace("whether", "weather")

;-)
 
Yes

Armin Zingler said:
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
Click to expand...
 
If DoEvents should not be used any more, why is it in the language?

application.doevents

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
 
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.VisualBasic 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
 
If DoEvents should not be used any more, why is it in the language?
Click to expand...

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.doevents

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

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?
Click to expand...

I haven't met him yet. ;-)


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

To write something more, maybe you remember that I 5 years ago wrote a
message just to prettend that somebody could told that he got the advice
from somebody in the newsgroups, while the result of that could be go wrong.

That was the only reason of my message.

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

Legacy code support.
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?
Click to expand...

Just as GoTo is the quickest way, in terms of code, to branch to another
part of your sub or function. It's still included even in VB 2008.

I wouldn't recommend using it, anymore than I'd recommend using DoEvents
though ;-)
 
Back
Top