Home » Eclipse Projects » Nebula » Re: Blank view when implementing CTableTree 
| Re: Blank view when implementing CTableTree [message #9318] | 
Mon, 21 August 2006 09:04  | 
 
Eclipse User  | 
 | 
 | 
   | 
 
Hi Cal, 
 
I'm cross posting to bring this over to the Nebula newsgroup, please 
post follow-ups regarding CTableTree there, thanks. 
 
 
Cal wrote: 
> 1. I've added org.aspencloud.widgets, org.aspencloud.widgets.ctabletree, 
> .widgets_0.0.1 and ..viewers_0.0.1 both dated 5/2/06 
 
These are really outdated (and will continue to change as they are all 
still pre-alpha - currently at 0.3.0).  The best thing would be to check 
the project out from Nebula's CVS so you'll have the latest.  The 
javadocs have been updated significantly since then as well, and there 
are some snippets which you should find helpful. 
 
> 1.CTableTree is a tree structure in which each CTableTreeItem can can 
> have multiple columns. The tree hierarchy can be in any one of those 
> columns. 
 
This is correct, though it defaults to be a flat table without a tree in 
any column. 
 
Overall, CTableTree was created with two main objectives: 1. allow items 
to expand and collapse individually; and 2. allow individual cell 
classes to be written separately from the implementation of the tree 
(which also allows a tree to be created in the view of one plugin, and 
cells to be created later by other plugins). 
 
> 2.A CTableTreeItem is a container for (or "can" be a container for) an 
> swt control, in my case a Text control. 
 
Actually a CTableTreeItem is more like a connector between the 
CTableTree, some data object, and one or more CTableTreeCells. 
 
Just like with the native tree, if you want to add data to it, you 
create a new item with the tree as its parent and then set the 
image/text for each column based on the data object.  The difference 
with the CTableTree is that each column of each item is a separate cell 
class - when an item is created, it iterates through each column 
creating cells of the types requested (by passing an array of cell Class 
objects to its constructor), if no type is requested for a given column, 
the item creates a "base" cell, which mostly just mimics a native one. 
There is a snippet in CVS which shows passing this array into the item's 
constructor. 
 
So, the Text Control you mention above would actually be in the 
CTableTreeCell, and the cell is accessed through the item by its column 
number.  The base implementation of a CTableTreeCell can display an 
array of images and a string, but subclasses have a lot of freedom to 
add functionality. 
 
> 3.The setCellProvider() determines which class to use(render?) when the 
> cell is expanded. So if I have some model object with a description 
> field, on expansion, I can have a Text box rendered where 
> Text.getText()=description. 
 
The cell provider determines which class of cell to create for a given 
element (the data object which corresponds to the item) and column 
number.  Basically, when the CTableTreeViewer needs to create a new 
CTableTreeItem, it asks the cell provider for the array of Class objects 
 to pass to the item's constructor and thus use when creating its cells 
(which are created via reflection). 
 
Now, similar to an ExpandableComposite, CTableTreeCells have two 
"regions" - a title area, and a child area. 
For the "base" implementation, the title area is drawn directly using 
the GC (the CTableTree will call a paint method in each cell and pass 
its own GC in).  There is no child area. 
If the cell is created with the SWT.SIMPLE style, then the title area is 
a composite and controls can be placed on it. 
If the cell is created with the SWT.DROP_DOWN style, then the child area 
will be created, controls can be placed on it, and it can be expanded 
and collapsed - though it will NOT be created until the first time it is 
expanded.  Also, if you create a cell with this style, you may be 
surprised to not see a Toggle.  Well, there's nothing stopping someone 
from implementing their own, so in order to not conflict with this, the 
SWT.TOGGLE style needs to be set for the cell to use its own 
implementation of a toggle. 
 
So, it sounds like you should create something like the following: 
 
public class MyCell extends CTableTreeCell { 
 
 private Text text; 
	 
 public MyCell(CContainerItem item, int style) { 
  super(item, style | SWT.DROP_DOWN | SWT.TOGGLE); 
 } 
 
 protected void createChildContents(SComposite contents, int style) { 
  contents.setLayout(new FillLayout()); 
  text = new Text(contents, SWT.MULTI | SWT.WRAP); 
 } 
 
 protected List getColorManagedControls() { 
  List list = super.getColorManagedControls(); 
  list.remove(text); 
  return list; 
 } 
	 
 protected List getEventManagedControls() { 
  List list = super.getEventManagedControls(); 
  list.remove(text); 
  return list; 
 } 
 
} 
 
Note the two getXXXControls() methods.  In order to set and show 
selection of items, the colors and events need to be handled by the 
CTableTree.  If you don't want the text control's background to change 
with the item's selection state then it needs to be removed from the 
list of "ColorManagedControls".  Likewise, if you want to be able to 
edit the text control, then you have to remove it from the list of 
"EventManagedControls" or else it will never receive mouse, focus, 
keyboard, etc., events. 
 
 
> 4. My label provider provides the caption for the tableTreeItem and my 
> content provider manages(?) the model objects. 
 
Correct, with one small difference.  Custom cells may or may not respond 
to the setting of images and text because custom cells can be anything. 
 To handle this, each cell contains an update() method which is called 
by the Viewer.  So for your class above, you would override this method 
with something like: 
 
 public boolean update(Object element, String[] properties) { 
  text.setText( ((MyModel) element).getDescription() ); 
  return super.update(element, properties); 
 } 
 
refer to the "doUpdateItem" method in CContainerViewer.java to get a 
better idea of how the Viewer is handling this (this class is in the 
"nebface" part of Nebula). 
 
> I havent gotten it to display properly yet, so I'm missing something... 
 
An implementation process might be as follows: 
1. implement the table/tree just as you would a SWT one 
2. implement the custom features, such as tree column & empty message 
3. create the custom cell class(es) 
4. implement the cell provider 
 
Take a look at the latest Nebula source and snippets in CVS; there are 
also two example cells in with the snippets which should help quite a 
bit.  The only difficulty on your part *should* be creating the custom 
cell class, but like I mentioned earlier, this is still pre-alpha :) 
Let me know your thoughts on the MultiLineCell in the snippets and we'll 
work on it from there. 
 
cheers
 |  
 |  
  |   
Goto Forum:
 
 Current Time: Tue Nov 04 02:28:25 EST 2025 
 Powered by  FUDForum. Page generated in 0.05876 seconds  
 |