> 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.) > 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. I don't mean to throw cold water on the open source grid control though. I like the idea and am happy to help crank through the API issues. Here are some more needs that might not have been expressed: - Variable-height row data implies that the grid can repaginate itself on demand, such as during a resize. 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.) - Double-clicking a column divider should size the column so that it just fits the largest data in that column. - Asynchronous grid loading. (Of course this fights with the previous feature.) - Column headers that can be more than just one line tall, and that can be custom-drawn. lj _______________________________________________ Unsubscribe or switch delivery mode: <http://www.realsoftware.com/support/listmanager/> Search the archives: <http://support.realsoftware.com/listarchives/lists.html>
