Re: [ve-dev] running sweet

["David J. Orme" <djo@xxxxxxxxxxxxxxxxxxxxxxxxx>]

Okay.  But if you have a specific use-case, I'd be glad to hear it.


Thanks,

Dave Orme

Mark Proctor wrote:

> For my current application its not needed, more thinking long term and 
> the suitability to spreadsheet type operations.
>
> Mark
> David J. Orme wrote:
>
> > Mark Proctor wrote:
> >
> > > virtual table stuff sounds great.
> >
> >
> >
> > Thanks!
> >
> > > With regards to merge I mean if you merge two cells, one above the 
> > > other, or even a block of 4x4 cells. 
> >
> >
> >
> > Okay, I know what you mean now.
> >
> > With CompositeTable it is simple to create a checkbook registry type 
> > layout where some pair (or n) rows repeat.  Just use a GridLayout to 
> > lay out your prototype row object however you like.
> >
> > Horizontal merges are also possible by programming your row object to 
> > handle that for you.
> >
> > But you can't just randomly merge cells vertically.
> >
> > > I'm guessing that veritcal or block cell merging can be done by 
> > > placing a floating composite that covers the 4x4 cells as the 
> > > rectangle top left and bottom right can be calculated - or maybe we 
> > > only need to set its width and height and anchor the top and left. 
> > > How would this compare GC based rendering performance? Any issues?
> >
> >
> >
> > That would be a real kludgy way to get the job done.  If 
> > CompositeTable exposed more of its redraw events to the outside, you 
> > could do it.
> >
> > But I really want to understand the use-case for doing this.  (In 
> > over 10 years of database application programming, I've never seen a 
> > use-case for this, so I have to admit that I'm stumped here.)
> >
> > Here's where I'm coming from:
> >
> > In any grid that is fundamentally editing rows from a collection or 
> > ResultSet, you're going to have repeating groups of things where each 
> > visual "thing" in the group represents a row in the 
> > collection/resultset.  So it seems to me that at some level, you're 
> > just going to model this whole collection of things as a row that can 
> > repeat n times where n is determined by the amount of visible space.  
> > Within that row, you might merge vertical cells, which you can do 
> > today in CompositeTable by using a GridLayout/GridData with 
> > verticalSpan > 1 on appropriate objects.  But I don't understand the 
> > use-case for merging vertical cells across boundaries that represent 
> > rows in your collection.
> >
> > > jxtable is a nice open source jtable implementation, that has some 
> > > extra features like frozen columns:
> > > http://xframe.sourceforge.net/swing/jxtable.html
> >
> >
> >
> > Yes.  Frozen columns would be very nice.  CompositeTable currently 
> > don't handle the case where you need to scroll horizontally.  Right 
> > now it makes your columns fit exactly in the visible space and 
> > allocates each column a programmer-specified percentage of the 
> > whole--which works fine for 80% of the cases.  But there are the 20% 
> > that need to scroll horizontally and this still needs work.
> >
> >
> > Regards,
> >
> > Dave Orme
>
> _______________________________________________
> ve-dev mailing list
> ve-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/ve-dev



--
Objects are here to stay.  http://www.db4o.com

PGP Public Key (for confidential communications):
http://www.coconut-palm-software.com/~djo/public_key.txt