|
|
| Re: tableTreeViewer.reveal & Decorators [message #16295 is a reply to message #16269] |
Sun, 05 November 2006 16:39   |
 Cal
Messages: 70
Registered: July 2009 |
Member |
|
|
>For the first issue with CTableTree.reveal(), please follow bug #162138 (add
>comments too if you have time). Issues such as this should be better handled
in >the future when CTableTree's identity crisis is over :)
ok.
>The decorators I haven't used before - please add a bug for them with your
>example code.
ok again:) I should add that it might not be ctabletree at all, just my
code!
>The third issue with the "selected but no-focus" foreground color sounds like
>another win32 emulation problem - what color is the text in a native table
for >this situation?
when you select an item in a tree the colours are as you have them, if you
give focus to something else, like clicking in the editor, the background
changes to the background colour as you have it but the font goes to
black. Ctabletree leaves the foreground as white so its hard to read the
text against the new background.
>Also, are the lines between tree nodes drawing correctly now?
Yes! Though the section of the line parallel to the childArea is not being
drawn, but I'm not complaining, It's great! Also you were right about the
computeSize function and the scrolling, it was partly me not calculating
correctly for my use case, my titleHeight varies depending on whether or
not the ctableTreeItem has any children + I added extra 5 spaces between
each item. So 3 calculations are possible. The height may be short enough
to fit on 1 line, if it has children, two lines are used. For leaf items
all text is displayed up in the titleArea so height is dependent on amount
of text. I got that sorted out *but* I was still having problems with the
bodySize. I narrowed it down to a problem with leaf nodes. A call to
getText() would return an empty string so tSize.y would always be zero, I
countered by just keeping a variable with the fulltext and it
works...again...it could be my code, I'm calling setText() in the
update(), getBounds() and setOpen() in my cell not sure if all that is
necessary was just trying to get the text to update.
Another issue that I discovered really because of the varying titleHeight
for my use case. If useFixedTitleHeight=false titleHeight is never set,
its at 0. I noticed because it caused an issue with my toggle selection,
(toggleHeight=titleHeight btw I'm using the SWT.DROP_DOWN). I dont know if
this issue would pose a problem for anyone else it doesnt seem to affect
anything if the title is only one line.
|
|
|
|
|
|
| Re: tableTreeViewer.reveal & Decorators [message #568159 is a reply to message #16269] |
Sun, 05 November 2006 16:39 |
Cal
Messages: 70
Registered: July 2009 |
Member |
|
|
>For the first issue with CTableTree.reveal(), please follow bug #162138 (add
>comments too if you have time). Issues such as this should be better handled
in >the future when CTableTree's identity crisis is over :)
ok.
>The decorators I haven't used before - please add a bug for them with your
>example code.
ok again:) I should add that it might not be ctabletree at all, just my
code!
>The third issue with the "selected but no-focus" foreground color sounds like
>another win32 emulation problem - what color is the text in a native table
for >this situation?
when you select an item in a tree the colours are as you have them, if you
give focus to something else, like clicking in the editor, the background
changes to the background colour as you have it but the font goes to
black. Ctabletree leaves the foreground as white so its hard to read the
text against the new background.
>Also, are the lines between tree nodes drawing correctly now?
Yes! Though the section of the line parallel to the childArea is not being
drawn, but I'm not complaining, It's great! Also you were right about the
computeSize function and the scrolling, it was partly me not calculating
correctly for my use case, my titleHeight varies depending on whether or
not the ctableTreeItem has any children + I added extra 5 spaces between
each item. So 3 calculations are possible. The height may be short enough
to fit on 1 line, if it has children, two lines are used. For leaf items
all text is displayed up in the titleArea so height is dependent on amount
of text. I got that sorted out *but* I was still having problems with the
bodySize. I narrowed it down to a problem with leaf nodes. A call to
getText() would return an empty string so tSize.y would always be zero, I
countered by just keeping a variable with the fulltext and it
works...again...it could be my code, I'm calling setText() in the
update(), getBounds() and setOpen() in my cell not sure if all that is
necessary was just trying to get the text to update.
Another issue that I discovered really because of the varying titleHeight
for my use case. If useFixedTitleHeight=false titleHeight is never set,
its at 0. I noticed because it caused an issue with my toggle selection,
(toggleHeight=titleHeight btw I'm using the SWT.DROP_DOWN). I dont know if
this issue would pose a problem for anyone else it doesnt seem to affect
anything if the title is only one line.
|
|
|
|
|
Powered by
FUDForum. Page generated in 0.03381 seconds
] 
Search
Help
Register
Login
Home
