At 3:39 PM -0500 2/15/06, Tom Buchler wrote:
I'm trying to get my head around this.
I think it's easiest to understand if you break the problem into two scenarios, and you need to support both:
1. Paint event driven updates: The Paint event fires whenever RB or the OS need you to redraw whatever is supposed to be currently showing in the canvas. The canvas itself does NOT store your image and so when your window becomes visible after being obscured, the OS and RB fire the Paint event to tell you to redraw whatever the canvas' previous contents were.
The Paint event fires to notify you to do the redraw. You can either redraw everything from scratch, or you might choose to keep a picture around of what you drew previously. Keeping a picture will use more memory, but it will be faster and produce less flicker on OS9 and Windows.
2. Application driven updates: The second scenario is when YOU decide that you need/want to change whatever is showing in the canvas. Whenever YOU need to change the canvas, you should directly draw to it.
NEVER use Refresh to force the canvas to refresh itself. Refresh will first erase the canvas and a short time later the Paint event will fire. And while your app is working on doing the redrawing, the canvas is sitting there EMPTY. This is what causes the flicker.
On OS9 and windows systems it's best to do all your drawing to a picture and then draw the finished picture to the canvas in one call to DrawPicture. This way the screen is never erased, it's never blank, it just goes instantly from the old image to the new image.
If you hang onto this picture, you can use it in the Paint event to flickerlessly update the canvas if RB should ever ask you to.
In summary, think of the Paint event as simply REDRAWING what was already showing, and use your own graphics.Draw calls to CHANGE what should be shown.
And don't ever call Refresh...it's almost as evil as DoEvents. :-) Just kidding, but it's close.
_______________________________________________ Unsubscribe or switch delivery mode: <http://www.realsoftware.com/support/listmanager/> Search the archives of this list here: <http://support.realsoftware.com/listarchives/lists.html>
