Hi Joe,
On May 15, 2007, at 10:33 AM, [EMAIL PROTECTED] wrote: > Your use of this technique in a Listbox inspires me to wonder whether > we can decouple these two problems: > only 2 problems? ;) > 1. Drawing and managing controls within a clipped graphics context > (such as a canvas, listbox cell, or grid cell) > The only technique like this I"ve actually used in a real app has been to add bevel buttons to the listbox, like the ones in this screenshot here: http://www.sentman.com/img/omnistat.jpg Thats all done with the standard RB listbox and custom drawing in the cells. They function like regular pushbuttons because I trap the mouse down and up events and cause the listbox cell to redraw with them being passed the new state. The drawing coordinates are global to the window and not the control and you have to account for scrolling of the listbox (the vertical scroll value times the row height to calculate where you should draw them. But when you do that they completely honor the clipping region of the cell and the listbox (or canvas) that you're drawing into. So the clipping region is set properly at that time, no further processing of it is necessary if you're drawing them yourself. The pain comes in when you have to then handle their behavior since just a bunch of calls to drawThemeButton dont give you the same thing as an actual control. I have experimented with other controls, mostly the relevance bar, the progress bar and the checkbox, and they all seem to work the same way as far as clipping. It's only the controls that RB draws for us that fail to clip. Which makes me think that either the interface objects from the OS dont honor the current clipping region properly (unlikely but possible) or RB simply clears the clipping rect before it tells the embedded controls to refresh themselves. Or before they get the message, however that is queued out. > 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 haven't had to do this since RB added the DrawCellText event ;) I played with some similar things back in the dark ages of like version 1 and 2, but nothing recently... > 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. This has caused me and a bunch of others enough pain that I'm sure there are a number of us that would be willing to throw some cash into the pot. If RB isn't interested in fixing it themselves, (and they should be because it makes the container control which is a pro feature, completely useless to me. I remember when it was announced finally that they were going to do it I laid awake nights thinking of all the clever and amazing interfaces I'd be able to do... Only to find it broken from day 1 because of this) perhaps we could take up a collection and buy a bug fix... -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>
