The correct way is for the Canvas to draw itself in its Paint event.
Don't know what else to say here... Yes, nothing disallows drawing to
the canvas's graphics from outside, but it's not how you do things if
you want to benefit from buffered canvases and other things that
assume you're drawing the "correct" way. Sorry.
This is kinda funny, because I had this discussion with my Dad (who
writes fun stuff in REALbasic) a couple months ago, and he was pretty
irritated with me until he "got it" about how to work with canvases.
Again, sorry.
-Brad
On Feb 15, 2006, at 9:14 AM, Tom Buchler wrote:
I've been reading Aaron's article regarding DoubleBufferedCanvas
(http://ramblings.aaronballman.com/?p=376). One of his comments
(and the whole thrust of the article) is that the class he designed
is largely supposed to act as a drop-in replacement for the built-
in canvas control.
I feel particularly dense today -- but I don't see the "normal" or
"correct" one uses a canvas control where this works. I've got code
sitting outside the canvas, responding to mouse-clicks, button-
clicks, etc. that invoke various routines that set the font and
color, draw lines and draw text, etc. on Canvas1.graphics. In fact,
we build a Graphics method that returns nil so that the user is
forced to use the control "correctly."
What is the proper way to selectively draw and redraw arbitrary
stuff to a Canvas from the surrounding app where
DoubleBufferedCanvas would work as conceived?
-Tom
_______________________________________________
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>
