On May 16, 2007, at 07:55 UTC, Lars Jensen wrote: > > But, if your grid is a list of tasks in progress, there's a good > > argument to be made for using standard progress bars... > > Why elevate these over other native controls? A progress bar is as > simple as it gets to simulate. (And I agree about not wanting a grid > full of throbbing neon worms, even on OS X.)
It's only simple if you abandon the standard (throbbing neon worm) look, and some developers (and users) prefer not to do that. > > I suppose the ideal would be a grid control that lets you embed > > standard controls, but if you run into glitches or don't like the > look, > > you could ignore that feature and draw your own. > > Yes, but only if there are no unpleasant side effects from the > "standard controls" feature for those who don't care about it. I'm > not convinced such a thing is possible. Even if one can ignore the > inevitable runtime glitches and cross-platform glitches, there would > probably be API glitches, which are the worst. This thing should Just > Work. Agreed, but I don't see why embedded control support should cause any particular grief if you're not using it. But that does depend on how it's done, of course. > - Variable-height row data implies that the grid can repaginate > itself on demand, such as during a resize. Can you explain what you mean by "repaginate"? > It can also ripple into > the printing model, and the presence or absence of a horizontal > scroll bar. And it can complicate the data provider model. (I'm > working on one of these, I'll post the code if there is interest.) My current thinking is that the actual drawing of the data would be up to you, in the equivalent of a CellTextPaint event. So, it would also be up to you to set the height of each row (that differs from the default row height). > - Double-clicking a column divider should size the column so that it > just fits the largest data in that column. That's an interesting one. I think I'd provide a DividerDoubleClicked event, and (again) let you deal with it. > - Asynchronous grid loading. (Of course this fights with the previous > feature.) Aha, but not with my you-handle-it design. :) But here's the neat bit: given a base class with no data storage, and events for drawing and handling double-clicks and whatnot, one could then add one or more subclasses that store or fetch data and handle those events for you. I like this approach because, when you're trying to do something like asynchronous data loading, you're not fighting the underlying design; you have a nice clean dataless base to build on. But when you just want a simple data container that knows how to handle itself, you can get that too. > - Column headers that can be more than just one line tall, and that > can be custom-drawn. Yeah, guess what I've been thinking with regard to drawing the headers. :) This is a tougher one to get right cross-platform, though, so we might want to provide some helper methods that can at least draw the proper background for a header cell, and maybe the text and sort icons too. Cheers, - Joe -- 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>
