Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » Nebula » variable CTableTreeCell
variable CTableTreeCell [message #11220] Sat, 09 September 2006 01:40 Go to next message
Eclipse User
Originally posted by: alnospammajor.noboxspamspoon.com

i'm wondering if there's a recommended way to provide a different
Composite in the title area of a Cell depending on the exact
type/contents of the element.

at first glance this appears problematic because createTitleContents is
called during Cell construction. whereas the element isn't made
available until the update is called.

on a related note, it's not clear to me how the column number is being
passed into update. the properties variable appears to be set to
getStringColumnProperties() which seems to be an array of properties
from all columns.

TIA,

regards,

al
Re: variable CTableTreeCell [message #11374 is a reply to message #11220] Mon, 18 September 2006 13:02 Go to previous messageGo to next message
Jeremy Dowdall is currently offline Jeremy Dowdall
Messages: 181
Registered: July 2009
Senior Member
Al,

Sorry for the huge delay in my response, I should be around more this week.

Al Major wrote:
> i'm wondering if there's a recommended way to provide a different
> Composite in the title area of a Cell depending on the exact
> type/contents of the element.
use the update method to modify the contents of the title area just as
you would for a detail composite in a master/detail block (the same goes
for the child area too, if you start using that, just keep in mind that
the child area may be null when update gets called if the user has never
expanded the cell).

> at first glance this appears problematic because createTitleContents is
> called during Cell construction. whereas the element isn't made
> available until the update is called.
createTitleContents creates the title composite, but does not require
that you fill it, you can wait until update is called for that, or you
can even wait until the item is actually painted (see the
addPaintedItemListener method in CContainer).
The only thing to keep in mind is that the more you can delay what gets
created upon initialization, the faster the cell (and the item) can be
created and added to the table. If every cell needs to create and
initialize a GEF model adding 1,000 items at once could take quite some
time! This was the initial reason behind the title area and the child
area - the title area was used to draw simple identifying information
about something (the name and description of the figure), and put that
something (the figure itself) into the drop down child area, similar to
a master/detail block. There are times however, when the title area is
a better location for the whole thing, and accomplishing this is still
in process of being worked out.

> on a related note, it's not clear to me how the column number is being
> passed into update. the properties variable appears to be set to
> getStringColumnProperties() which seems to be an array of properties
> from all columns.
the simple answer is that it is not passed in :)
a CContainerItem contains an array of CContainerCells; in the subclass,
CTableTreeItem, the index of each cell (CTableTreeCells in this case) is
also its column number, so a cell can always get its column number by
asking its containing item for its own index:
int col = Arrays.asList(item.cells).indexOf(this);
Perhaps CContainerItem should include a method such as: int
getCellIndex(CContainerCell)... ?
As for the properties variable... this just plain looks like a bug due
to oversight. The cell could find the pertinent string property using
its index as found above, but it would probably be better to just pass
the single, relevant, property in the first place. If you have a
chance, please file a bug.
Re: variable CTableTreeCell [message #11448 is a reply to message #11374] Mon, 18 September 2006 18:43 Go to previous messageGo to next message
Eclipse User
Originally posted by: alnospammajor.noboxspamspoon.com

> createTitleContents creates the title composite, but does not require
> that you fill it, you can wait until update is called for that, or you
> can even wait until the item is actually painted (see the
> addPaintedItemListener method in CContainer).

i'll check this out. i like the flexibility of lazy initialization. i'm
not sure if i agree completely with using a paint listener as the form
of the callback interface (seems overly specific), but i'll see what the
implementation looks like before i comment further.

> The only thing to keep in mind is that the more you can delay what gets
> created upon initialization, the faster the cell (and the item) can be
> created and added to the table. If every cell needs to create and
> initialize a GEF model adding 1,000 items at once could take quite some
> time! This was the initial reason behind the title area and the child
> area - the title area was used to draw simple identifying information
> about something (the name and description of the figure), and put that
> something (the figure itself) into the drop down child area, similar to
> a master/detail block. There are times however, when the title area is
> a better location for the whole thing, and accomplishing this is still
> in process of being worked out.
>
in my application i do need the GEF viewer to be visible in the title
area. possibly even more than one per row. so obviously, lazy
initialization / "tree virtualization" is pure goodness :-).


>> on a related note, it's not clear to me how the column number is being
>> passed into update. the properties variable appears to be set to
>> getStringColumnProperties() which seems to be an array of properties
>> from all columns.
> the simple answer is that it is not passed in :)
> a CContainerItem contains an array of CContainerCells; in the subclass,
> CTableTreeItem, the index of each cell (CTableTreeCells in this case) is
> also its column number, so a cell can always get its column number by
> asking its containing item for its own index:
> int col = Arrays.asList(item.cells).indexOf(this);

thanks!

> Perhaps CContainerItem should include a method such as: int
> getCellIndex(CContainerCell)... ?

yeah, some kind of formal abstraction would appear to be called for.
again, i won't have specific feedback until i see what the code wants to
do :-)

> As for the properties variable... this just plain looks like a bug due
> to oversight. The cell could find the pertinent string property using
> its index as found above, but it would probably be better to just pass
> the single, relevant, property in the first place. If you have a
> chance, please file a bug.

seems like it falls under the rubric of unnecessary/unused API? how
does one file a bug for that?

thx,

al
Re: variable CTableTreeCell [message #11485 is a reply to message #11374] Mon, 18 September 2006 18:56 Go to previous messageGo to next message
Eclipse User
Originally posted by: alnospammajor.noboxspamspoon.com

> createTitleContents creates the title composite, but does not require
> that you fill it, you can wait until update is called for that, or you
> can even wait until the item is actually painted (see the
> addPaintedItemListener method in CContainer).

i have a use case where up to half the cells that are created will
remain blank (show the background color). i know resources are
relatively cheap these days but it seems wasteful to have that many
empty child composites sitting around.

thx,

al
Re: variable CTableTreeCell [message #11522 is a reply to message #11374] Mon, 18 September 2006 19:03 Go to previous messageGo to next message
Eclipse User
Originally posted by: alnospammajor.noboxspamspoon.com

Jeremy Dowdall wrote:
> a CContainerItem contains an array of CContainerCells; in the subclass,
> CTableTreeItem, the index of each cell (CTableTreeCells in this case) is
> also its column number, so a cell can always get its column number by
> asking its containing item for its own index:
> int col = Arrays.asList(item.cells).indexOf(this);

item.cells isn't visible from the subclass of CContainerCell. so either
the visibility needs to be changed or (preferably) some API needs to be
created to address the use case. the following seems reasonable for now.

> Perhaps CContainerItem should include a method such as: int
> getCellIndex(CContainerCell)... ?

a more general API may be needed if the columns need to be draggable
(more generally, reordered) in the future. but this is a start.

al
Re: variable CTableTreeCell [message #11559 is a reply to message #11448] Mon, 18 September 2006 22:30 Go to previous messageGo to next message
Jeremy Dowdall is currently offline Jeremy Dowdall
Messages: 181
Registered: July 2009
Senior Member
> i'll check this out. i like the flexibility of lazy initialization.
> i'm not sure if i agree completely with using a paint listener as the
> form of the callback interface (seems overly specific), but i'll see
> what the implementation looks like before i comment further.

This is not a paint listener, it's a "painted item listener" which is
fired any time item's go in or out of view, and are thus painted when
they previously were not, or are not painted when they previously were.

There are four lists in a CContainer:
1. items - all the items in the order they were created
2. orderedItems - all the items in the order to be drawn on screen
3. visibleItems - all the items in the order to be drawn on screen
which _could_ actually be drawn
4. paintedItems - all the items in the order to be drawn on screen
which _are_ actually drawn

it is when the paintedItems list is modified that listeners are notified.
Re: variable CTableTreeCell [message #11595 is a reply to message #11522] Tue, 19 September 2006 13:00 Go to previous messageGo to next message
Jeremy Dowdall is currently offline Jeremy Dowdall
Messages: 181
Registered: July 2009
Senior Member
Al Major wrote:
> item.cells isn't visible from the subclass of CContainerCell. so
> either the visibility needs to be changed or (preferably) some API needs
> to be created to address the use case. the following seems reasonable
> for now.

doh! :)

>
>> Perhaps CContainerItem should include a method such as: int
>> getCellIndex(CContainerCell)... ?

The above has been implemented and is in CVS.

> a more general API may be needed if the columns need to be draggable
> (more generally, reordered) in the future. but this is a start.

Agreed. This will also mix in with refactoring the properties array - I
thought I'd read there was some work in JFace for abstracting out the
column numbers... ?
Re: variable CTableTreeCell [message #11631 is a reply to message #11485] Tue, 19 September 2006 13:11 Go to previous messageGo to next message
Jeremy Dowdall is currently offline Jeremy Dowdall
Messages: 181
Registered: July 2009
Senior Member
> i have a use case where up to half the cells that are created will
> remain blank (show the background color). i know resources are
> relatively cheap these days but it seems wasteful to have that many
> empty child composites sitting around.

The Cell provider used by CTableTreeViewer passes the element in when
asking for the cell classes so you could pass it a different
(base/empty) cell for those particular elements.
Having noted that, I can also see what a pain this could be when you
simply want to "null-out" the title area composite - a case for a lazy
title area is making more and more sense, so I've made the following
changes:
Creation of the title area occurs in a new method: createTitleArea().
If the constructor's style param has SWT.TITLE active, then the
createContents method will call createTitleArea() and the cell will be
built just as it was previously. If SWT.TITLE is not active, however,
the title area will not be created and subclasses will be able to create
the title area whenever they want by calling createTitleArea() themselves.
Would you foresee a need for a disposeTitleArea() method?
Re: variable CTableTreeCell [message #11847 is a reply to message #11631] Thu, 21 September 2006 20:18 Go to previous messageGo to next message
Eclipse User
Originally posted by: alnospammajor.noboxspamspoon.com

Jeremy Dowdall wrote:
>
> The Cell provider used by CTableTreeViewer passes the element in when
> asking for the cell classes so you could pass it a different
> (base/empty) cell for those particular elements.
> Having noted that, I can also see what a pain this could be when you
> simply want to "null-out" the title area composite - a case for a lazy
> title area is making more and more sense, so I've made the following
> changes:

i'm not sure i know how to do this. i'll take a look at this as soon as
i can.

> Creation of the title area occurs in a new method: createTitleArea().
> If the constructor's style param has SWT.TITLE active, then the
> createContents method will call createTitleArea() and the cell will be
> built just as it was previously. If SWT.TITLE is not active, however,
this sounds reasonable, as long as this is the understood usage of
SWT.TITLE.

> the title area will not be created and subclasses will be able to create
> the title area whenever they want by calling createTitleArea() themselves.
> Would you foresee a need for a disposeTitleArea() method?
right now, i can't see the need for a dispose... method, but that may
change.

thanks for making all the changes so quickly!!

al
Re: variable CTableTreeCell [message #12475 is a reply to message #11847] Fri, 22 September 2006 11:34 Go to previous message
Jeremy Dowdall is currently offline Jeremy Dowdall
Messages: 181
Registered: July 2009
Senior Member
the ICContainerCellProvider has one method:
public abstract Class[] getCellClasses(Object element);
which is called by the viewer when asked to create a new item. The
element parameter is passed in by the viewer, so in your implementation
you can return a different Class array for each element, based on its
type/condition/etc.

This is, of course, only helpful at creation time... the changes
mentioned below allow for better reaction to the element at runtime.

Al Major wrote:
> Jeremy Dowdall wrote:
>>
>> The Cell provider used by CTableTreeViewer passes the element in when
>> asking for the cell classes so you could pass it a different
>> (base/empty) cell for those particular elements.
>> Having noted that, I can also see what a pain this could be when you
>> simply want to "null-out" the title area composite - a case for a lazy
>> title area is making more and more sense, so I've made the following
>> changes:
>
> i'm not sure i know how to do this. i'll take a look at this as soon
> as i can.
>
>> Creation of the title area occurs in a new method: createTitleArea().
>> If the constructor's style param has SWT.TITLE active, then the
>> createContents method will call createTitleArea() and the cell will be
>> built just as it was previously. If SWT.TITLE is not active, however,
> this sounds reasonable, as long as this is the understood usage of
> SWT.TITLE.
>
>> the title area will not be created and subclasses will be able to create
>> the title area whenever they want by calling createTitleArea()
>> themselves.
>> Would you foresee a need for a disposeTitleArea() method?
> right now, i can't see the need for a dispose... method, but that
> may change.
>
> thanks for making all the changes so quickly!!
>
> al
Re: variable CTableTreeCell [message #565061 is a reply to message #11220] Mon, 18 September 2006 13:02 Go to previous message
Jeremy Dowdall is currently offline Jeremy Dowdall
Messages: 181
Registered: July 2009
Senior Member
Al,

Sorry for the huge delay in my response, I should be around more this week.

Al Major wrote:
> i'm wondering if there's a recommended way to provide a different
> Composite in the title area of a Cell depending on the exact
> type/contents of the element.
use the update method to modify the contents of the title area just as
you would for a detail composite in a master/detail block (the same goes
for the child area too, if you start using that, just keep in mind that
the child area may be null when update gets called if the user has never
expanded the cell).

> at first glance this appears problematic because createTitleContents is
> called during Cell construction. whereas the element isn't made
> available until the update is called.
createTitleContents creates the title composite, but does not require
that you fill it, you can wait until update is called for that, or you
can even wait until the item is actually painted (see the
addPaintedItemListener method in CContainer).
The only thing to keep in mind is that the more you can delay what gets
created upon initialization, the faster the cell (and the item) can be
created and added to the table. If every cell needs to create and
initialize a GEF model adding 1,000 items at once could take quite some
time! This was the initial reason behind the title area and the child
area - the title area was used to draw simple identifying information
about something (the name and description of the figure), and put that
something (the figure itself) into the drop down child area, similar to
a master/detail block. There are times however, when the title area is
a better location for the whole thing, and accomplishing this is still
in process of being worked out.

> on a related note, it's not clear to me how the column number is being
> passed into update. the properties variable appears to be set to
> getStringColumnProperties() which seems to be an array of properties
> from all columns.
the simple answer is that it is not passed in :)
a CContainerItem contains an array of CContainerCells; in the subclass,
CTableTreeItem, the index of each cell (CTableTreeCells in this case) is
also its column number, so a cell can always get its column number by
asking its containing item for its own index:
int col = Arrays.asList(item.cells).indexOf(this);
Perhaps CContainerItem should include a method such as: int
getCellIndex(CContainerCell)... ?
As for the properties variable... this just plain looks like a bug due
to oversight. The cell could find the pertinent string property using
its index as found above, but it would probably be better to just pass
the single, relevant, property in the first place. If you have a
chance, please file a bug.
Re: variable CTableTreeCell [message #565111 is a reply to message #11374] Mon, 18 September 2006 18:43 Go to previous message
Al Major is currently offline Al Major
Messages: 72
Registered: July 2009
Member
> createTitleContents creates the title composite, but does not require
> that you fill it, you can wait until update is called for that, or you
> can even wait until the item is actually painted (see the
> addPaintedItemListener method in CContainer).

i'll check this out. i like the flexibility of lazy initialization. i'm
not sure if i agree completely with using a paint listener as the form
of the callback interface (seems overly specific), but i'll see what the
implementation looks like before i comment further.

> The only thing to keep in mind is that the more you can delay what gets
> created upon initialization, the faster the cell (and the item) can be
> created and added to the table. If every cell needs to create and
> initialize a GEF model adding 1,000 items at once could take quite some
> time! This was the initial reason behind the title area and the child
> area - the title area was used to draw simple identifying information
> about something (the name and description of the figure), and put that
> something (the figure itself) into the drop down child area, similar to
> a master/detail block. There are times however, when the title area is
> a better location for the whole thing, and accomplishing this is still
> in process of being worked out.
>
in my application i do need the GEF viewer to be visible in the title
area. possibly even more than one per row. so obviously, lazy
initialization / "tree virtualization" is pure goodness :-).


>> on a related note, it's not clear to me how the column number is being
>> passed into update. the properties variable appears to be set to
>> getStringColumnProperties() which seems to be an array of properties
>> from all columns.
> the simple answer is that it is not passed in :)
> a CContainerItem contains an array of CContainerCells; in the subclass,
> CTableTreeItem, the index of each cell (CTableTreeCells in this case) is
> also its column number, so a cell can always get its column number by
> asking its containing item for its own index:
> int col = Arrays.asList(item.cells).indexOf(this);

thanks!

> Perhaps CContainerItem should include a method such as: int
> getCellIndex(CContainerCell)... ?

yeah, some kind of formal abstraction would appear to be called for.
again, i won't have specific feedback until i see what the code wants to
do :-)

> As for the properties variable... this just plain looks like a bug due
> to oversight. The cell could find the pertinent string property using
> its index as found above, but it would probably be better to just pass
> the single, relevant, property in the first place. If you have a
> chance, please file a bug.

seems like it falls under the rubric of unnecessary/unused API? how
does one file a bug for that?

thx,

al
Re: variable CTableTreeCell [message #565136 is a reply to message #11374] Mon, 18 September 2006 18:56 Go to previous message
Al Major is currently offline Al Major
Messages: 72
Registered: July 2009
Member
> createTitleContents creates the title composite, but does not require
> that you fill it, you can wait until update is called for that, or you
> can even wait until the item is actually painted (see the
> addPaintedItemListener method in CContainer).

i have a use case where up to half the cells that are created will
remain blank (show the background color). i know resources are
relatively cheap these days but it seems wasteful to have that many
empty child composites sitting around.

thx,

al
Re: variable CTableTreeCell [message #565162 is a reply to message #11374] Mon, 18 September 2006 19:03 Go to previous message
Al Major is currently offline Al Major
Messages: 72
Registered: July 2009
Member
Jeremy Dowdall wrote:
> a CContainerItem contains an array of CContainerCells; in the subclass,
> CTableTreeItem, the index of each cell (CTableTreeCells in this case) is
> also its column number, so a cell can always get its column number by
> asking its containing item for its own index:
> int col = Arrays.asList(item.cells).indexOf(this);

item.cells isn't visible from the subclass of CContainerCell. so either
the visibility needs to be changed or (preferably) some API needs to be
created to address the use case. the following seems reasonable for now.

> Perhaps CContainerItem should include a method such as: int
> getCellIndex(CContainerCell)... ?

a more general API may be needed if the columns need to be draggable
(more generally, reordered) in the future. but this is a start.

al
Re: variable CTableTreeCell [message #565179 is a reply to message #11448] Mon, 18 September 2006 22:30 Go to previous message
Jeremy Dowdall is currently offline Jeremy Dowdall
Messages: 181
Registered: July 2009
Senior Member
> i'll check this out. i like the flexibility of lazy initialization.
> i'm not sure if i agree completely with using a paint listener as the
> form of the callback interface (seems overly specific), but i'll see
> what the implementation looks like before i comment further.

This is not a paint listener, it's a "painted item listener" which is
fired any time item's go in or out of view, and are thus painted when
they previously were not, or are not painted when they previously were.

There are four lists in a CContainer:
1. items - all the items in the order they were created
2. orderedItems - all the items in the order to be drawn on screen
3. visibleItems - all the items in the order to be drawn on screen
which _could_ actually be drawn
4. paintedItems - all the items in the order to be drawn on screen
which _are_ actually drawn

it is when the paintedItems list is modified that listeners are notified.
Re: variable CTableTreeCell [message #565205 is a reply to message #11522] Tue, 19 September 2006 13:00 Go to previous message
Jeremy Dowdall is currently offline Jeremy Dowdall
Messages: 181
Registered: July 2009
Senior Member
Al Major wrote:
> item.cells isn't visible from the subclass of CContainerCell. so
> either the visibility needs to be changed or (preferably) some API needs
> to be created to address the use case. the following seems reasonable
> for now.

doh! :)

>
>> Perhaps CContainerItem should include a method such as: int
>> getCellIndex(CContainerCell)... ?

The above has been implemented and is in CVS.

> a more general API may be needed if the columns need to be draggable
> (more generally, reordered) in the future. but this is a start.

Agreed. This will also mix in with refactoring the properties array - I
thought I'd read there was some work in JFace for abstracting out the
column numbers... ?
Re: variable CTableTreeCell [message #565231 is a reply to message #11485] Tue, 19 September 2006 13:11 Go to previous message
Jeremy Dowdall is currently offline Jeremy Dowdall
Messages: 181
Registered: July 2009
Senior Member
> i have a use case where up to half the cells that are created will
> remain blank (show the background color). i know resources are
> relatively cheap these days but it seems wasteful to have that many
> empty child composites sitting around.

The Cell provider used by CTableTreeViewer passes the element in when
asking for the cell classes so you could pass it a different
(base/empty) cell for those particular elements.
Having noted that, I can also see what a pain this could be when you
simply want to "null-out" the title area composite - a case for a lazy
title area is making more and more sense, so I've made the following
changes:
Creation of the title area occurs in a new method: createTitleArea().
If the constructor's style param has SWT.TITLE active, then the
createContents method will call createTitleArea() and the cell will be
built just as it was previously. If SWT.TITLE is not active, however,
the title area will not be created and subclasses will be able to create
the title area whenever they want by calling createTitleArea() themselves.
Would you foresee a need for a disposeTitleArea() method?
Re: variable CTableTreeCell [message #565401 is a reply to message #11631] Thu, 21 September 2006 20:18 Go to previous message
Al Major is currently offline Al Major
Messages: 72
Registered: July 2009
Member
Jeremy Dowdall wrote:
>
> The Cell provider used by CTableTreeViewer passes the element in when
> asking for the cell classes so you could pass it a different
> (base/empty) cell for those particular elements.
> Having noted that, I can also see what a pain this could be when you
> simply want to "null-out" the title area composite - a case for a lazy
> title area is making more and more sense, so I've made the following
> changes:

i'm not sure i know how to do this. i'll take a look at this as soon as
i can.

> Creation of the title area occurs in a new method: createTitleArea().
> If the constructor's style param has SWT.TITLE active, then the
> createContents method will call createTitleArea() and the cell will be
> built just as it was previously. If SWT.TITLE is not active, however,
this sounds reasonable, as long as this is the understood usage of
SWT.TITLE.

> the title area will not be created and subclasses will be able to create
> the title area whenever they want by calling createTitleArea() themselves.
> Would you foresee a need for a disposeTitleArea() method?
right now, i can't see the need for a dispose... method, but that may
change.

thanks for making all the changes so quickly!!

al
Re: variable CTableTreeCell [message #565504 is a reply to message #11847] Fri, 22 September 2006 11:34 Go to previous message
Jeremy Dowdall is currently offline Jeremy Dowdall
Messages: 181
Registered: July 2009
Senior Member
the ICContainerCellProvider has one method:
public abstract Class[] getCellClasses(Object element);
which is called by the viewer when asked to create a new item. The
element parameter is passed in by the viewer, so in your implementation
you can return a different Class array for each element, based on its
type/condition/etc.

This is, of course, only helpful at creation time... the changes
mentioned below allow for better reaction to the element at runtime.

Al Major wrote:
> Jeremy Dowdall wrote:
>>
>> The Cell provider used by CTableTreeViewer passes the element in when
>> asking for the cell classes so you could pass it a different
>> (base/empty) cell for those particular elements.
>> Having noted that, I can also see what a pain this could be when you
>> simply want to "null-out" the title area composite - a case for a lazy
>> title area is making more and more sense, so I've made the following
>> changes:
>
> i'm not sure i know how to do this. i'll take a look at this as soon
> as i can.
>
>> Creation of the title area occurs in a new method: createTitleArea().
>> If the constructor's style param has SWT.TITLE active, then the
>> createContents method will call createTitleArea() and the cell will be
>> built just as it was previously. If SWT.TITLE is not active, however,
> this sounds reasonable, as long as this is the understood usage of
> SWT.TITLE.
>
>> the title area will not be created and subclasses will be able to create
>> the title area whenever they want by calling createTitleArea()
>> themselves.
>> Would you foresee a need for a disposeTitleArea() method?
> right now, i can't see the need for a dispose... method, but that
> may change.
>
> thanks for making all the changes so quickly!!
>
> al
Previous Topic:Alpha dist needs updated to reflect Snippet changes
Next Topic:GEF viewer in CTableTreeCell
Goto Forum:
  


Current Time: Fri Oct 24 16:23:42 GMT 2014

Powered by FUDForum. Page generated in 0.02616 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software