Hi Joe (and everyone else), Thanks for the help! I've started experimenting with this, and tbh it gives me a much more flexible aprroach than my current canvas-heavy interface. The downside is that it's tricker to manage, but it gives me some major benefits:
I can make my interface truly object-oriented without needing to use ContainerControls, and manage a true parent / child tree of custom controls I can take complete control of the redraw process I think I'll end up with much less redrawing going on! I'll let you all know how this goes :-) Dave. > From: "Joseph J. Strout" <[EMAIL PROTECTED]> > Reply-To: REALbasic NUG <[email protected]> > Date: Mon, 13 Feb 2006 10:56:50 -0700 > To: REALbasic NUG <[email protected]> > Subject: Re: Double-buffered windows on Windows > > At 5:16 PM +0000 2/13/06, Dave Addey wrote: > >> Thanks for the tip. Unfortunately, I don't know how else to achieve the >> interface I have: >> >> http://www.dj1800.com/images/fullscreen.gif >> >> Each of the control elements (knobs, sliders etc.) is a canvas (actually a >> custom subclass of a canvas). > > Well, you'd have to stop approaching it that way. Each control > element could still be an object, but it wouldn't be derived from > Canvas; it would just be derived from some base class that you would > make up. This base class would probably have Top, Left, Width, and > Height properties, just like a Canvas, and a drawing method or event. > Each of the subclasses would have to draw relative to their Top/Left > values, rather than to 0,0, since you can't shift the graphics origin > as the Canvas class does. But otherwise, these classes wouldn't have > to change too much. > > Your window would have just one giant Canvas -- or perhas, no canvas > at all -- and just keep a list of all the control elements. It would > handle the Paint event by having all the controls draw into an > offscreen buffer, and then drawing this buffer to the screen (thus > eliminating the flicker). It would handle mouse events by zipping > through the list, finding out which one contains the mouse, and > calling the handler on that item. > > When a control needs to repaint itself, things get slightly more > tricky: they need to tell the owner (the canvas or window) that the > need redrawn, and then it must make call Paint on on each interface > element within its bounds, again to the offscreen buffer. Then it > copies just that portion of the offscreen buffer to the screen. This > will be much faster than redrawing the entire window, yet still > eliminate flicker. > >> Using canvases as the control elements provides an excellent way for me to >> deal with the controls as objects and subclasses. > > Well, it provides *a* way to do it. But not the best way, as you > have discovered, in cases where the objects need to overlap. You can > still implement them as objects and subclasses; you just need to take > control of the drawing and mouse-interfacing yourself. > > Best, > - Joe > > P.S. I love the interface -- gorgeous work! > > -- > > Joseph J. Strout > [EMAIL PROTECTED] > _______________________________________________ > 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> _______________________________________________ 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>
