Sorry to jump in. But you might want to check this out,
http://geekswithblogs.net/jolson/articles/2173.aspx
This guy explains why you shouldn't use DoEvents in a game loop, and it's
pretty much for the same reason (in my opinion), especially if you are just
using it to enable the redrawing of a thread blocked form. *But*, that
doesn't mean you shouldn't use DoEvents full stop, you can "selectively"
yield to the operator by checking the message cue for any pending messages
*before* calling DoEvents, use the following to achieve this,
Private Const QS_HOTKEY As Integer = &H80
Private Const QS_KEY As Integer = &H1
Private Const QS_MOUSEBUTTON As Integer = &H4
Private Const QS_MOUSEMOVE As Integer = &H2
Private Const QS_PAINT As Integer = &H20
Private Const QS_POSTMESSAGE As Integer = &H8
Private Const QS_SENDMESSAGE As Integer = &H40
Private Const QS_TIMER As Integer = &H10
Private Const QS_ALLPOSTMESSAGE As Integer = &H100
Private Const QS_MOUSE As Integer = (QS_MOUSEMOVE Or QS_MOUSEBUTTON)
Private Const QS_INPUT As Integer = (QS_MOUSE Or QS_KEY)
Private Const QS_ALLEVENTS As Integer = (QS_INPUT Or QS_POSTMESSAGE Or
QS_TIMER Or QS_PAINT Or QS_HOTKEY)
Private Const QS_ALLINPUT As Integer = (QS_SENDMESSAGE Or QS_PAINT Or
QS_TIMER Or QS_POSTMESSAGE Or QS_MOUSEBUTTON Or QS_MOUSEMOVE Or QS_HOTKEY Or
QS_KEY)
Private Declare Function GetQueueStatus Lib "user32" (ByVal fuFlags As
Integer) As Integer
Public Sub selectiveYield()
If (CBool(GetQueueStatus(QS_ALLINPUT))) Then Call Application.DoEvents()
End Sub
I'm sure that Landers solution sounds more robust, but this can be
quickly implemented at key points during the application to prevent your
loop from slowing down unneccesarily by yielding with each loop. Hope this
helps.
Nick.
"Chris" <chris@No_Spam_Please.com> wrote in message
news:eN**************@TK2MSFTNGP09.phx.gbl...
Landley-
Your post has brought up a couple of questions in my mind.
First, I use the DoEvents in several places in my application to make sure
the screen is in a clean state, is this a bad practice in general. For
instance I have a point where I got grab a bunch of data after a combobox
is changed. The combobox freezes and doesn't redraw until the blocking
call is done, so I run a doevents and it works perfect.
Not shown in that code I gave is a call to another sub that shows a
progress bar so the user sees something happening while loading. There
are many DB calls to get the data needed to show the user and there is a
decent delay in processing it all. I think I need the DoEvents for this
progress bar to update nicely, do you disagree with using it in this
instance still?
Chris
"Landley" <ne**@creations-software.co.uk> wrote in message
news:eZ**************@TK2MSFTNGP14.phx.gbl... Chris,
Firstly, try to avoid using DoEvents. There are many situations where
this
could prove deadly to your applications.
I would suggest showing the splash screen. Use ThreadStart to start your
job with a waithandle or a class that derrives the waithandle. This way,
you do not need a "nasty" loop containing DoEvents.
Hope this helps.
Landers
"Chris" <chris@No_Spam_Please.com> wrote in message
news:uW**************@TK2MSFTNGP12.phx.gbl... I have a form that take a bit to load up because of talking to a
database
and the amount of data process that has to take place before showing the
screen. I have it working but I feel that I horked it into working. I
was wondering if there was a better way to do this. Here are the two
interesting pieces of code. Thanks in Advance.
Sub Main
Dim Splash As New SplashScreen
Dim t As System.Threading.Thread
t = New System.Threading.Thread(AddressOf Splash.Process)
Splash.Show()
t.Start()
Dim CF As CommissionForm = New CommissionForm()
Splash.TimeToDie = True
t.Abort()
CF.ShowDialog()
End Sub
'This is Splash Screen code
Public Sub Process()
Do While Not Die
Application.DoEvents()
System.Threading.Thread.CurrentThread.Sleep(125)
Loop
Me.Hide()
Me.Close()
End Sub