On May 15, 2007, at 12:49 UTC, James Sentman wrote: > It's not just progress bars, most controls will quite happily > continue to draw themselves right out of the clipping region of > whatever container control or canvas that you're moving them around > in.
Yes, I picked on Progress Bars just to avoid solutions that involve taking a picture of the control and drawing that. That's a sort-of solution that will work for some kinds of controls, but not for any animated control. > This has been a bug for a really long time. You can signon to > this bug report which was opened in 2004.. nzoejfez Thanks, that looks like the one. I would add (if the feedback system would let me!) that the window does not need to be composite for this bug to occur. > My work around for embedding controls in most things now is to call > directly to the DrawTheme methods via declares. For something like a > progress bar you have to continually redraw it so that it will move, > but this is less overhead than drawing a regular RB control to an > invisible window and trying to blit that over to the real window. Yes, that's certainly true. > And > it does not make it easy since you have to handle all the stuff that > RB normally takes care of for you. I've mostly used it to embed > controls into a listbox cell. (though there should probably be a > feature request in there to insert a container control into a listbox > cell come to think of it, now THAT would be cool!) and I had to > handle all the drawing and UI interaction in my own code. Thats not > too hard for a couple of pushbuttons, but anything more and it > quickly becomes an exercise in frustration. Well, it certainly is a lot of work, that's for sure. This is essentially the same thing I want to do, but for a grid control (very similar to a listbox in many ways) rather than the RB listbox. Your use of this technique in a Listbox inspires me to wonder whether we can decouple these two problems: 1. Drawing and managing controls within a clipped graphics context (such as a canvas, listbox cell, or grid cell) 2. Production of a "grid" control that's similar to a listbox, but more cell-oriented than row-oriented and which supports freezing and merging of cells. I know how to do 2, but I'm still a little vague on 1. For MacOS, solutions have been proposed that involve declares to either the CG clipping routines, or to just draw the controls with DrawTheme calls. I'm not sure, but I suspect that on other platforms, standard control parentage takes care of it for us. Of course a better solution for 1 would be for RS to fix bug nzoejfez, and then we don't need to go to such Herculean efforts. Best, - Joe > Thanks! > James Sentman <http://www.MacHomeAutomation.com/> > _______________________________________________ > Unsubscribe or switch delivery mode: > <http://www.realsoftware.com/support/listmanager/> > > Search the archives: > <http://support.realsoftware.com/listarchives/lists.html> > -- Joe Strout -- [EMAIL PROTECTED] Strout Custom Solutions _______________________________________________ Unsubscribe or switch delivery mode: <http://www.realsoftware.com/support/listmanager/> Search the archives: <http://support.realsoftware.com/listarchives/lists.html>
