Hi Tom the progress on the bug you showed me is very promising! The 'problem' with the current celleditors is a pure productivity issue in my 'database-browser' rcp-client. Users complain that my users feel like there's one click too much, the one that's needed to activate the cell editor (and there's a supplementary one when the celleditor has a dialog). What they would like to have is something that feels like excel where you just start to edit when you're there.
Greets André > Hi Andre, > > what is the problem with CellEditors, I think we are in 3.3 very close > to provide Excel-Like features in SWT. > In 3.3M6 we are going to introduce the following: > - configureable editor activation (SingleClick,DoubleClick, ...) > - (configureable) keyboard cell navigation > - tabediting in cells > > If you are interested please take a look at the following bug: > https://bugs.eclipse.org/bugs/show_bug.cgi?id=172646 > > > André Dietisheim schrieb: >> Hi Dave, Hi Ivan >> >> thanks a lot for your feedback! >> I definitively underestimated the heavyweight-scalability. The widget >> I need is a classic table (JTable, SWT Table) without any special >> cell-capabilities. My choice towards Compositetable was due to the >> presumed possibility to allow an Excel-like editability (no >> celleditors) and the several bugs still present in virtual >> tableViewer. >> >> In the tests (30*30 cells) I made, I get the best results when I use >> canvas as cells, but the performance is still not fluid enough. I'll >> have to decide on monday if I still use CompositeTable for the current >> customer, but time is running and my customer change is due end of >> march. I therefore probably will try to patch the current tableViewer >> and try to fix the last documented bug. The time necessar for this try >> is affordable. Another alternative would be to try to reimplement my >> table using KTable that performs very well. >> On the other hand, i still could get some regular worktime (after my >> customer change) to continue compositeTable if I see a way to achieve >> my goal to implement a large, cell-based table. >> >> What about using canvas for rows and draw all cells with gc (or >> draw2d-figures?) - similar to ktable? In this scenario all accesses to >> column-'controls' would have to be refactored to a more generic >> TableRow-class and a subclasses GridRowLayout could be used. I assume >> the changes in CompositeTable would be very important but worth the >> performance increase for regular tables. What do you think of this >> approach? >> >> Regards >> André >> >> On Thu, 2007-03-08 at 19:15 -0600, David J. Orme wrote: >> >>>> 1.) the whole rcp app dies with SWTError: no more handles >>>> I'll analyze this by using sleak but I suppose that this will not >>>> >>> help a >>> >>>> lot as i'll reach the limit very soon by opening a second >>>> >>> editor-tab. >>> >>>> This lets me think that it's not possible to display cells by >>>> >>> individual >>> >>>> controls. On the other hand traversal relies on these controls. Any >>>> >>> ideas >>> >>>> here? >>>> >>> Yeah; since CompositeTable creates a control for every cell, you have >>> to be careful. >>> >>> Thoughts: Can you reduce the number of native controls in your row >>> object? Maybe you can draw part of your row on a canvas rather than >>> making everything heavy-weight? This is how DayEditor (built on >>> CompositeTable) works. >>> >>> Sometimes CompositeTable isn't the right solution. If you need >>> something that has to scale to lots of visible rows/columns, maybe >>> KTable or the SWT Table are the right solution. >>> >>> >>>> 2.) layout (I use native header) is terribly slow. The table takes >>>> >>> up to 2 >>> >>>> minutes to display and resize. >>>> I probably could solve that performance issue by improving the >>>> >>> resizing or >>> >>>> using another header. any ideas? >>>> >>> Layout should scale linearly with the number of controls. However, >>> CompositeTable uses lots more controls than other solutions. So >>> either you need to go less native (draw more stuff on a GC), have >>> fewer controls in a given table, or you need another solution. >>> >>> Using another solution probably means either that you have to break >>> your table down into more smaller tables or you might need to use a >>> different table control. >>> >>> >>> Regards, >>> >>> Dave Orme >>> >>> >>> _______________________________________________ >>> nebula-dev mailing list >>> [email protected] >>> https://dev.eclipse.org/mailman/listinfo/nebula-dev >>> >>> >>> !DSPAM:45f0a83319851044727653! >>> >> >> _______________________________________________ >> nebula-dev mailing list >> [email protected] >> https://dev.eclipse.org/mailman/listinfo/nebula-dev >> > > _______________________________________________ > nebula-dev mailing list > [email protected] > https://dev.eclipse.org/mailman/listinfo/nebula-dev > > > !DSPAM:45f455ca81621058516758! -- André Dietisheim Stv-Bereichsleiter Products Puzzle ITC GmbH Eigerplatz 4 CH-3007 Bern Telefon +41 31 370 22 00 Mobile +41 76 423 03 02 Fax +41 31 370 22 01 Puzzle ist Mitglied der ODF Alliance: <http://www.puzzle.ch/odfalliance/> _______________________________________________ nebula-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/nebula-dev
