Canvas.Paint Not Called by Refresh

General
1

I have a Canvas that needs to refresh itself several times in the course of a method (contains multiple nested if statements with different actions). The canvas Refresh is called, but the canvas Paint event is not triggered until after the method completes, which means some interesting interim stuff is not displayed. I have also tried canvas Invalidate, but it does not change what is happening.

I found this thread: [Canvas.Refresh does not trigger immediately]

But the link to the code that was supposedly used to fix the problem does not work. Can anyone explain to me how to get the Paint event to be triggered repeatedly from within the method? Thanks.

2

You have 2 choices.

  1. Break up your code into sections, each followed by a canvas.invalidate. Run each section in a timer, keeping track of where you are. Eg.,
select case NextAction
case "Section1"
    // section1 code
    NextAction = "Section2"
case "Section2
    // section2 code
    NextAction = "Section3"
case "Section3"
    // section3 code
    NextAction = ""
end
canvas1.invalidate
// exit, let the canvas update and then run the next section of code
if NextAction <> "" then me.RunMode = Timer.RunModes.Single
  1. Put your code into a thread and yield after each canvas refresh/invalidate
3

You do not state if you are using Web 1.0 or Web 2.0 - well I guessed it’s a Web project.

In 1.0 the client was not updated until the end of a method. I wonder if in 2.0 it’s still the same though :thinking:.

4

Thanks. More of a rewrite than I was hoping for, but I can use a refresher on threads.

5

It’s actually an old desktop application that no longer works as it once did.

6

app.DoEvents()

within your method should do what you want, but it might cause unexpected results though.

from the documentation

Using DoEvents in a GUI application will likely cause instability . In effect, you would be placing a main event loop inside the “real” main event loop. You should consider using threadsto handle lengthy operations rather than placing them in the main thread and calling DoEvents to maintain the interface.

If the current method is running inside a Thread, DoEvents will yield to the main thread instead of running one iteration of the event loop inside the thread, causing confusion.

If you use DoEvents inside a loop, then you cannot use the UserCancelled function to detect whether the user pressed the Esc key (Windows or Linux) or Command-period (on Macintosh) to break out of the loop. Since DoEvents keeps the user interface responsive while the loop is running, you can add a button to the user interface that the user can click to stop the loop.