Home » Eclipse Projects » Nebula » variable CTableTreeCell
| variable CTableTreeCell [message #11220] |
Fri, 08 September 2006 21: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 09:02  |
| Eclipse User |
|
|
|
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 14: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 #12475 is a reply to message #11847] |
Fri, 22 September 2006 07:34 |
| Eclipse User |
|
|
|
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 09:02 |
| Eclipse User |
|
|
|
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 14:43 |
| Eclipse User |
|
|
|
> 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 14:56 |
| Eclipse User |
|
|
|
> 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 15:03 |
| Eclipse User |
|
|
|
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 18:30 |
| Eclipse User |
|
|
|
> 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 09:00 |
| Eclipse User |
|
|
|
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 09:11 |
| Eclipse User |
|
|
|
> 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 16:18 |
| Eclipse User |
|
|
|
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 07:34 |
| Eclipse User |
|
|
|
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: Thu May 08 06:47:58 EDT 2025
Powered by FUDForum. Page generated in 0.05040 seconds |
Home