Home » Eclipse Projects » Nebula » variable CTableTreeCell
| variable CTableTreeCell [message #11220] |
Sat, 09 September 2006 01:40  |
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  |
 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 |
| 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 |
| 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 |
| 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 #11847 is a reply to message #11631] |
Thu, 21 September 2006 20:18 |
| 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 |
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 |
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 |
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 #565504 is a reply to message #11847] |
Fri, 22 September 2006 11:34 |
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
|
|
|
Goto Forum:
Current Time: Fri Jan 03 03:45:04 GMT 2025
Powered by FUDForum. Page generated in 0.06376 seconds |
] 
Search
Help
Register
Login
Home
