This brings up another point. If this is "how everyone does it", why
doesn't RB do it for everyone? Virtually every example of drawing to
a canvas in RB documentation draws directly in the paint event using
simple draw commands. If it were as simple as drawing to a picture
the size of the canvas' graphics and drawing the picture in the
paint event, this should be automatic and invisible.
I found out, through difficult trial-and-error and help from this
list, that following the examples in the docs results in bad windows
performance (a flash on every draw). Drawing to a picture and drawing
to the picture in the paint event does not help. The fix is to use
'canvas1.graphics' and do your drawing there (frequently a picture).
At some stage in RB's evolution this began to work (In early docs,
like the "Definitive Guide", it states that drawing to a canvas'
graphics will do nothing, you must cause a 'paint' event to fire).
My experience is that there are no coherent description of what a
canvas is nor are there rules about how to draw to a canvas.
As to why it is difficult to get to a canvas' graphics property, I
think its because the this object does not contain anything -- I
think it's more like a pipe to the screen buffer. This is a guess
from its performance and memory of a Joe Strout message on this list
many moons ago.
John Kubie
On Jul 16, 2006, at 4:27 AM, Maarten de Vries wrote:
I don't see why you have to get a picture from the canvas. Just
draw to a
picture first, and draw that to the canvas. That's how everybody
does it (I
think). The canvas.BackDrop property even saves the time of making
a new
variable, like Th
_______________________________________________
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>
