DoEvents not working

[Cor Ligthert]

Hi Hefried,

Be sure that I read the thread. The problem will go away when using
multithreading.

Show me where this will help, I changed the code to make it testable, this
works very good.
However when I bring the loop down to 10000 it is almost impossible to reach
the cancel button.

So show me what the multithread can do to help this with a loop of 2000
records in the dataset, without slowing the loop down.(The recordset loop
needs probably much less time, because there is no screen painting)

I spent some time on it, so I expect an answer.

Cor

\\\
Private CancelPrint As Boolean
Private Sub Form1_Load(ByVal sender As Object, _
ByVal e As System.EventArgs) Handles MyBase.Load
Me.Button1.Text = "Start"
Me.ProgressBar1.Maximum = 1000000
Me.ProgressBar1.Value = 1
End Sub
Private Sub CmdCancel_Click(ByVal sender As System.Object, _
ByVal e As System.EventArgs) Handles Button2.Click
CancelPrint = True
End Sub
Private Sub Button1_Click(ByVal sender As System.Object, _
ByVal e As System.EventArgs) Handles Button1.Click
Dim a As Integer
CancelPrint = False
Button2.Focus()
Do While ProgressBar1.Value < ProgressBar1.Maximum _
And CancelPrint = False
Application.DoEvents()
ProgressBar1.Value += 1
Loop
If CancelPrint Then
MsgBox("Printing Canceled By User", MsgBoxStyle.Exclamation)
End If
End Sub
///

 

[Herfried K. Wagner [MVP]]

Show me where this will help, I changed the code to make it testable, this
works very good.
However when I bring the loop down to 10000 it is almost impossible to reach
the cancel button.

The OP didn't tell us how long the loop takes to execute.

So show me what the multithread can do to help this with a loop of 2000
records in the dataset, without slowing the loop down.(The recordset loop
needs probably much less time, because there is no screen painting)

It depends on what you are actually doing with the data.

 

[Cor Ligthert]

The OP didn't tell us how long the loop takes to execute.

Did you ask it to him?

I asked however he did not give an answer on that, after he got the right
answer from MVP Herfried K. Wagner that to use applications.doevents it
absolutly is necessary to use as well multithreading.

And do not say you did not say, you did explicitly said that 2 or more
times.

Cor

 

[Herfried K. Wagner [MVP]]

Did you ask it to him?
No.

I asked however he did not give an answer on that, after he got the right
answer from MVP Herfried K. Wagner that to use applications.doevents it
absolutly is necessary to use as well multithreading.

LOL!

 

[P. Prosper]

Hello both,
Sorry I was away for the weekend
to clarify the situation ...
I agree that iterating through 10000 records would not give me the time to
click the button. But as posted in my initial Post, the loop take over 10
minutes to complete (thanks to the lines wher crptStatement (crystal report
statement) appear)

yes the button is enabled . I did try setting a break in the button click
event but it does'nt even get there.
I tried :
If i = 100 Then

CmdCancel.PerformClick()

'End If

inside the loop and the logic does work. It's seems as if the crystal report
is blocking the thread to the point where the click event does'nt get
executed.


Dim crptStatement As New crptStatements_ATH
If ChkNotificacion.CheckState = CheckState.Unchecked Then
crptStatement.Section7.SectionFormat.EnableSuppress = True
Else
crptStatement.Section7.SectionFormat.EnableSuppress = False
End If
crptStatement.RecordSelectionFormula = SelFormula
i = i + 1
ProgressBar1.Value = i
crptStatement.PrintToPrinter(1, False, 0, 0)

 

[Armin Zingler]

Hello both,
Sorry I was away for the weekend
to clarify the situation ...
I agree that iterating through 10000 records would not give me the
time to click the button. But as posted in my initial Post, the loop
take over 10 minutes to complete (thanks to the lines wher
crptStatement (crystal report statement) appear)

yes the button is enabled . I did try setting a break in the button
click event but it does'nt even get there.
I tried :
If i = 100 Then

CmdCancel.PerformClick()

'End If

inside the loop and the logic does work. It's seems as if the crystal
report is blocking the thread to the point where the click event
does'nt get executed.

DoEvents should be sufficient to be able to click the button.

I'm still interested in: Does the button change the visual state when
holding down the mouse?

Maybe the form looses focus when CR starts printing.


Replace a single call of application.doevents by this (only for testing):

dim start as integer
start = environment.tickcount

do
application.doevents
loop until environment.tickcount - start > 2000 orelse CancelPrint

if cancelprint then stop


Try again and see if the button can be clicked and the stop statement is
reached.
Don't forget to remove your CmdCancel.PerformClick. ;-)


--
Armin

How to quote and why:
http://www.plig.net/nnq/nquote.html
http://www.netmeister.org/news/learn2quote.html

 

[P. Prosper]

IT WORKS !!!!
Before inserting your lines, Armin, the button would'nt change it's visual
state while clicking (all I had was a flashing hourglass cursor). It also
works if I insert the following lines inside the loop
Dim x As Integer

For x = 0 To 200

Application.DoEvents()

Next x

I's a performance hit but anyway the user has to wait for the printer to
digest the print jobs.

Seems that DoEvents does NOT process all the events in the queue after all.
I'm still puzzled why it would.nt work in the first place.

Thank you all so very much

 

[Herfried K. Wagner [MVP]]

IT WORKS !!!!
Before inserting your lines, Armin, the button would'nt change it's visual
state while clicking (all I had was a flashing hourglass cursor). It also
works if I insert the following lines inside the loop
Dim x As Integer

For x = 0 To 200

Application.DoEvents()

Next x

I's a performance hit but anyway the user has to wait for the printer to
digest the print jobs.

Seems that DoEvents does NOT process all the events in the queue after all.
I'm still puzzled why it would.nt work in the first place.

IMO performing all the stuff in a separate thread and checking a Boolean
variable that is set on button click is still the cleaner solution ;-).

 

[Cor Ligthert]

Hi Herfried,

IMO performing all the stuff in a separate thread and checking a Boolean
variable that is set on button click is still the cleaner solution ;-).

For printing it can be a nicer solution. However when there is need to print
first and than go on with the solution than not.

And the multithreading had not resolved the problem, it had made it even
more complex and that is always the wrong way to go to resolve a problem.

Cor

 

[Armin Zingler]

IT WORKS !!!!
Before inserting your lines, Armin, the button would'nt change it's
visual state while clicking (all I had was a flashing hourglass
cursor). It also works if I insert the following lines inside the
loop
Dim x As Integer

For x = 0 To 200

Application.DoEvents()

Next x

I's a performance hit but anyway the user has to wait for the
printer to digest the print jobs.

Seems that DoEvents does NOT process all the events in the queue
after all. I'm still puzzled why it would.nt work in the first
place.

Thank you all so very much

[Wanted to send this yesterday, but...]

Good to know it works now. Though, I'm intersted in why. I made the
suggestion because I believed to remember a short "printing page ..."
message coming from CR. If this was true, the Form (and the button) would
loose the focus for a very short period of time. If this happens while you
are holding down the button you won't get a click event anymore - unless you
press and release the moust button fast enough to be processed in a single
call to application.doevents. ;-) Still this is speculation. You could
handle the Button's lostfocus event to check this (debug.writeline
"lostfocus").

....

Meanwhile I tried to reproduce the problem (why not earlier?). The only
thing that came back into my mind was a different bug: If you try to click a
button during a loop containing application.doevents, not the button itself
is clicked but the button currently having the focus.

Anyway, while testing, my Button does not loose the focus and I can click
it. So my speculation was wrong... Sorry, I wished I found the solution.


--
Armin

How to quote and why:
http://www.plig.net/nnq/nquote.html
http://www.netmeister.org/news/learn2quote.html

 

[Cor Ligthert]

Hi Armin,

That lost focus I have also seen, that button.focus is in my sample to
Herfried too.
(Which not solves the problem by the way, that was your solution.)

Cor

 

[Herfried K. Wagner [MVP]]

IMO performing all the stuff in a separate thread and checking a Boolean
variable that is set on button click is still the cleaner solution ;-). [...]

And the multithreading had not resolved the problem, it had made it even
more complex and that is always the wrong way to go to resolve a problem.

Multithreading doesn't make it more complex, but you can better separate
the UI from data processing.

 

[Cor Ligthert]

Herfried,

Multithreading doesn't make it more complex, but you can better separate
the UI from data processing.

We make both a solution.

Show on a form the result in a label from the process 1 + 1

You use multithreading I not, let us look what is less complex.

However I think you are afraid to take this chalenge.

Cor

 

[Cor Ligthert]

Show on a form the result in a label from the process 1 + 1

private sub form load ...........
me.label.text= 1+1
end sub

I am curious for your multithreading solution

Cor

 

[Cor Ligthert]

Hi Herfried,

While I made my solution I forgot I wrote this nowhere in this thread.

Multithreading doesn't make it more complex, but you can better separate
the UI from data processing.

Multithreading makes the total processing time and the use of resources much
longer/higher when there is no external waiting time involved.

And therefore your statement is bs

A good sample for multithreading is printing when it is about huge printing
where the buffer is not able to process in time the printing. However
remoting is than even better.

Cor

 

[Herfried K. Wagner [MVP]]

Cor,

Multithreading makes the total processing time and the use of resources much
longer/higher when there is no external waiting time involved.

I don't see any reasons for that. IMO that's a typical case for
multithreading.

 

[Herfried K. Wagner [MVP]]

Cor,

We make both a solution.

I don't have enough time to do that.

Show on a form the result in a label from the process 1 + 1

You use multithreading I not, let us look what is less complex.

Mhm... I never said that there are any advantages with mutithreading if
there is a simple '1 + 1' calculcation in a loop. It's all about
/heavy/ working, like in the OP's case where the task takes about 10
minutes.

However I think you are afraid to take this chalenge.

I am not afraid, but I am not sure how you would like to interpret the
result? Even if the multithreading solution is slower, I don't think
that's a big problem, if the overall user experience is better.

 

[Herfried K. Wagner [MVP]]

private sub form load ...........
me.label.text= 1+1
end sub

I am curious for your multithreading solution

You are joking, aren't you?

 

[Cor Ligthert]

Hi Herfried,

I am joking of course, however see my sample.

What I try to say to you is that there are situations where multithreading
is good to use. And that is where there are much seperated parallel
processes where the sum of the processes make the result.

However in a sequential proces the single thread is always more efficient
because there is no threadmanagement needed.

When the sum of the processes is not important, than is remoting much more
efficient when there are parallel or especial semiparallel processes.
(However for most people to difficult to implement)

Cor

 

[P. Prosper]

Thought the thread was dead, but I guess I was wrong LOL ..
The truth is that putting a DoEvents in a loop fixed the problem this time
but I know I'll bump into the problem in the future again.

Again I'm still puzzled why it didn't work in the first place.

I haven't notice the "printing page ..." message. Also, I tried your
suggestion on setting a trap in the LostFocus event of CmdCancel but the
button did not lose focus (I did CmdCancel.Focus before entering the loop).

IT WORKS !!!!
Before inserting your lines, Armin, the button would'nt change it's
visual state while clicking (all I had was a flashing hourglass
cursor). It also works if I insert the following lines inside the
loop
Dim x As Integer

For x = 0 To 200

Application.DoEvents()

Next x

I's a performance hit but anyway the user has to wait for the
printer to digest the print jobs.

Seems that DoEvents does NOT process all the events in the queue
after all. I'm still puzzled why it would.nt work in the first
place.

Thank you all so very much

[Wanted to send this yesterday, but...]

Good to know it works now. Though, I'm intersted in why. I made the
suggestion because I believed to remember a short "printing page ..."
message coming from CR. If this was true, the Form (and the button) would
loose the focus for a very short period of time. If this happens while you
are holding down the button you won't get a click event anymore - unless you
press and release the moust button fast enough to be processed in a single
call to application.doevents. ;-) Still this is speculation. You could
handle the Button's lostfocus event to check this (debug.writeline
"lostfocus").

...

Meanwhile I tried to reproduce the problem (why not earlier?). The only
thing that came back into my mind was a different bug: If you try to click a
button during a loop containing application.doevents, not the button itself
is clicked but the button currently having the focus.

Anyway, while testing, my Button does not loose the focus and I can click
it. So my speculation was wrong... Sorry, I wished I found the solution.


--
Armin

How to quote and why:
http://www.plig.net/nnq/nquote.html
http://www.netmeister.org/news/learn2quote.html