On May 14, 2007, at 4:46 PM, [EMAIL PROTECTED] wrote: > On May 14, 2007, at 11:48 UTC, Marc (aliacta.com) wrote: > >> PS: my take on features needed for the next ListBox, as discussed >> several years ago on the NUG, is still: keep the current ListBox, >> add a new control that is a minimalist frame on which anybody can >> build what he wants. Something that simply provides flexible row >> heights and column widths, horizontal and vertical scrolling, styled >> cell contents, possibly with the ability to embed any control in a >> cell. > > I can certainly imagine something that relies entirely on the > equivalent of CellBackgroundPaint and CellTextPaint for its content, > but also supports variable row heights, merging of cells, and maybe > even freezing of N top rows and M left columns. > > Would we also require the ability to freeze some bottom rows and > rightmost columns?
I think the answer would be yes if you wanted to go all the way, but I believe that the 'freezing' should be for people to implement themselves. As a rule of thumb, the more features you'd implement, the harder it might get for people to do things that are not foreseen (e.g. current ListBox), whereas an 'empty' frame would leave all possibilities open. > As for embedding of controls in a cell -- that one is really hard, > especially cross-platform. I understand why you want it sometimes; > it's just quite difficult to do. Still, if it's important, and effort > were put in to enabling it from the very beginning, it could be doable > for at least most controls. It would be good to have at least the controls that are most used for databases, e.g. popup, checkbox, radio, canvas (for thumbnails), etc. And then each cell/control should be editable or not, enabled or not. > While we're at it, let's define more selection types: > > 0 - no selection allowed at all > 1 - single row > 2 - multiple rows > 3 - single column > 4 - multiple columns > 5 - single cell > 6 - any contiguous block of cells > 7 - discontiguous (arbitrary) cells > >> How it behaves, e.g. how it scrolls or populates itself, would >> be for each one of us to implement. > > Controlling scrolling can be complex, since it goes both ways (e.g. > the > user may scroll the content using the scrollbar, or by using the arrow > keys once a selection is established, or even while drag-selecting > with > the mouse). So I think you'd want this relationship between the > content and the scrollbars to be managed by the grid control. > However, > I can certainly imagine the scrollbars being separate controls, so > that > you can size and position them however you like. There might be a default implementation for scrolling, but here too I feel developers might have such a variety of needs that fully customized scrolling should be the rule. (As an example, if you have a lot of columns or they're simply very wide, you might want some form of horizontal scrolling that just skips a number of columns to speed navigation up.) > What do you think? I'm pushing on this because, to be frank, I'm so > tired of the whining about it that if we can agree on a reasonable > spec, I'll consider writing the dang thing and publishing it as open > source. That would certainly be very welcome. I thought of doing this myself several times over the past years but never came to it because the gruesome lack of time that governs many of people's lives, unfortunately including mine. Thanks! Marc _______________________________________________ Unsubscribe or switch delivery mode: <http://www.realsoftware.com/support/listmanager/> Search the archives: <http://support.realsoftware.com/listarchives/lists.html>
