hi lyle, TableItem cannot do some things the table can do on it''s items: the row and column index spanning? <=> table.itemSpanning? color(=) <=> table.s/getCellColor maybe also these two methods: startInput makePositionVisible would it make sense to add these methods to the interface of tableItem? since tableitem surely knows its table it should be no problem of forwarding the according method calls to the table instance. -- henon -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/fxruby-users/attachments/20060216/f33d5dd8/attachment-0001.htm
On Feb 16, 2006, at 8:06 AM, Meinrad Recheis wrote:> TableItem cannot do some things the table can do on it''s items: > > the row and column index > spanning? <=> table.itemSpanning? > color(=)? <=> table.s/getCellColor > > maybe also these two methods: > startInput > makePositionVisible > > would it make sense to add these methods to the interface of > tableItem? > since tableitem surely knows its table it should be no problem of > forwarding the according method calls to the table instance.Currently, the table items do not hold back pointers to the table that owns them. In order to use any of these functions from an FXTableItem instance, we''d need to add that additional data (or require it as an input argument). I have added this as a feature request, and we''ll see if it''s something we can do in 1.6.
On Thursday 16 February 2006 08:06, Meinrad Recheis wrote:> hi lyle, > TableItem cannot do some things the table can do on it''s items: > > the row and column index > spanning? <=> table.itemSpanning? > color(=) <=> table.s/getCellColor > > maybe also these two methods: > startInput > makePositionVisible > > would it make sense to add these methods to the interface of tableItem? > since tableitem surely knows its table it should be no problem of forwarding > the according method calls to the table instance.The FXTableItem''s interface is intended for FXTable, and the FXTable interface is meant for your programs. Thus, FXTableItem doesn''t know about FXTable except insofar as when FXTable is passed as a parameter sometimes. Certainly, it is the case that FXTableItem doesn''t know which cell it''s in, and so doesn''t know if it''s a spanning item either. I suggest strongly to manipulate items through FXTable and not via FXTableItem directly; manipulating via FXTableItem means FXTable isn''t aware anything has changed and thus doesn''t know it needs to update or recompute.... - Jeroen -- +----------------------------------------------------------------------------+ | Copyright (C) 16:40 02/16/2006 Jeroen van der Zijp. All Rights Reserved. | +----------------------------------------------------------------------------+ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://rubyforge.org/pipermail/fxruby-users/attachments/20060216/c55e5fb6/attachment.bin
On Thursday 16 February 2006 16:58, you wrote:> On 2/16/06, Jeroen van der Zijp <jeroen at fox-toolkit.org> wrote: > > > > On Thursday 16 February 2006 08:06, Meinrad Recheis wrote: > > > hi lyle, > > > TableItem cannot do some things the table can do on it''s items: > > > > > > the row and column index > > > spanning? <=> table.itemSpanning? > > > color(=) <=> table.s/getCellColor > > > > > > maybe also these two methods: > > > startInput > > > makePositionVisible > > > > > > would it make sense to add these methods to the interface of tableItem? > > > since tableitem surely knows its table it should be no problem of > > forwarding > > > the according method calls to the table instance. > > > > The FXTableItem''s interface is intended for FXTable, and the FXTable > > interface > > is meant for your programs. > > > > Thus, FXTableItem doesn''t know about FXTable except insofar as when > > FXTable is > > passed as a parameter sometimes. > > > > Certainly, it is the case that FXTableItem doesn''t know which cell it''s > > in, and > > so doesn''t know if it''s a spanning item either. > > > > I suggest strongly to manipulate items through FXTable and not via > > FXTableItem > > directly; manipulating via FXTableItem means FXTable isn''t aware anything > > has > > changed and thus doesn''t know it needs to update or recompute.... > > > pity. i was hoping that i did not need to use the fxtable interface to > manipulate items, because lyle > included methods each_row{|tableItemArray| } and > each_column{|tableItemArray| } in FXRuby. > the ruby way of manipulating complex structures is iterating over the > structure instead of loops and indexaccess. > > so i suggest for fxruby a complete rework of the tableitem in fxruby which > forwards its attribute manipulators to the > table interface. i did even implement this allready but then thought it was > not necessary because i thought that tableItem > had almost all attributes the table also provides in its interface.Sorry, this is how its done in C++; Lyle can clue you in on Ruby particulars... - Jeroen -- +----------------------------------------------------------------------------+ | Copyright (C) 17:00 02/16/2006 Jeroen van der Zijp. All Rights Reserved. | +----------------------------------------------------------------------------+ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://rubyforge.org/pipermail/fxruby-users/attachments/20060216/d6cfc075/attachment.bin