Home » Eclipse Projects » Standard Widget Toolkit (SWT) » An annoying tree control problem
| An annoying tree control problem [message #508336] |
Mon, 18 January 2010 13:39  |
 Waqas Ilyas
Messages: 80
Registered: July 2009 |
Member |
|
|
Hi,
I have a very annoying bug that I have been trying to fix. I am using using a tree control inside the GEF palette (on Windows XP), although I am not sure if this could be a factor. I am aware that the GEF palette is not meant to be used in this way but this is a project requirement, and either I would have created a completely new flyout panel or reused the default.
Problem:
The problem is that the tree stops painting itself. There is garbage screen content in the tree area and it stops responding to any mouse or keyboard events. It usually happens when I resize the workbench window, vertical resizing (as I have noticed) easily reproduces the problem. Also maximizing and restoring the window. However, if I resize the palette (tree's ancestor container), horizontally, the tree comes back.
Description:
The problem is not always reproducible but once it starts occurring it is consistent.
When the tree goes into this 'error state', if I call getItemCount() it will return 0, adding a new item causes SWT error ERROR_ITEM_NOT_ADDED. But on resizing the palette, it returns back with all its content intact. Sometimes it also returns to functional state when I make a selection else where in the editor, which was suppose to expand a tree node and select some node inside it.
I initially thought that since I am programatically resizing the columns, maybe its because of that, maybe the tree resizes to 0 size, and what I see is its parent composite. But this is not the case, in my efforts to track it down I have written small animators that paint lines continuously on the tree and all its parents up to the palette, but once this goes in the error state, there is no drawing in the tree area. It only seems to receive resize events.
I have removed bit by bit all my functionality associated with the tree, to locate the problem by elimination and stripped the tree down to a simple control (not even a viewer) with some dummy data in it. At this point sometimes the problem is not reproducible if i do not add any columns, sometimes it is not reproducible if i remove one of its composite parents and create the tree directly in its grand parent. But this is not a reliable finding. It has happened that one use case might cause a problem on one system and not on the other.
Even though I have written quite a detailed description above, it is definitely not enough so if you have any questions, please let me know. What I would really appreciate is if someone could guide me as to how I may go about tracking this problem down. I thought about debugging SWT C side code to see what actually fails when I try to add an item but I could not get the SWT C code to setup so far. I am willing to go down that road if it has some promise.
Any suggestions at all would be highly appreciated. Thanks in advance.
Waqas Ilyas
|
|
| |
| Re: An annoying tree control problem [message #508615 is a reply to message #508358] |
Tue, 19 January 2010 11:12  |
Grant Gayed
Messages: 2150
Registered: July 2009 |
Senior Member |
|
|
Hi Waqas,
This is a very strange problem, I've never heard of something like this
before. It's good that you've tried to reduce the case somewhat, but it
still sounds like there's still too much happening to make a guess on this
end of what the problem could be.
SWT's JNI calls map 1:1 to native calls, so when tracing through swt's
implementation you do not need to follow over to the C side. With the
exception of a small set of functions in os_custom.c, swt's C code is just
auto-gen'd to do some basic set-up, make the native call, do some basic
tear-down, and return the result from the native call.
When you receive ERROR_ITEM_NOT_ADDED you can try invoking OS.GetLastError()
to see if win32 gives a hint of what the problem is. Beyond this, all I can
suggest is to try to reduce your case further if possible (eg.- see if
whatever GEF is doing can be somewhat replaced with a few swt calls, etc.).
If you get some new findings or have more questions then you can follow up
here.
Good luck!
Grant
"Waqas Ilyas" <waqas.ilyas@gmail.com> wrote in message
news:hj1s0k$doi$1@build.eclipse.org...
> One thing I failed to mention was that there is no exception in the
background. There is none listed in the log and I also tried with
breakpoints over ClassCastException, IllegalStateException,
NullPointerException and SWTException.
|
|
| | |
| Re: An annoying tree control problem [message #508884 is a reply to message #508838] |
Wed, 20 January 2010 16:05 |
Grant Gayed
Messages: 2150
Registered: July 2009 |
Senior Member |
|
|
ERROR_ITEM_NOT_ADDED is returned if the TVM_INSERTITEM message that's sent
in Tree.createItem(...) fails to return the handle of a new native tree
item. Unfortunately the MSDN page at
http://msdn.microsoft.com/en-us/library/bb773733(VS.85).aspx does not give
much explaination of when this will fail.
Regarding the workbench window getting corrupted, I wonder if you're seeing
something like https://bugs.eclipse.org/bugs/show_bug.cgi?id=142965 . Can
you see if it helps to close as many apps running in your system tray as
possible? Some apps that have been known to make this happen are ultramon,
Logitech SetPoint and Hydravision. This list is not necessarily exhaustive
though, there could be others.
Grant
"Waqas Ilyas" <waqas.ilyas@gmail.com> wrote in message
news:hj73ag$lk4$1@build.eclipse.org...
> Another thing is that sometimes the entire Workbench window gets corrupted
and the contents (views, editors, menu bar, toolbar and status bar) are out
of place. But doing a minimze and maximize makes the UI correct again.
Although it does not fix the tree.
>
> I have also tried to comment out any "dipose" calls I was making for any
resource (GC, image, font, color etc) to make sure I am not disposing
anything that is being shared. I commented out only in code that was related
to this particular component. But this did not effect anything.
|
|
|
| Re: An annoying tree control problem [message #509345 is a reply to message #508336] |
Fri, 22 January 2010 07:57 |
Waqas Ilyas
Messages: 80
Registered: July 2009 |
Member |
|
|
Hi Grant,
I had actually already seen the msdn page for TVM_INSERTITEM, but I thought that someone here might have some additional clues. Apology in advance for the long post.
BTW, I am sorry I did not mention this before but I am using Eclipse 3.3.1.1 on a Windows XP machine with Nvidia Quadro NVS 290. I actually don't have Logitech Setpoint (I think) but I do have the logitech keyboard and mouse. I use Logitech iTouch. But this problem can also be seen on systems with no logitech peripherals.
I have done some additional testing based on your comments. I have gone through the entire comment list of the bug you mentioned, and all other bugs that were marked duplicate of this bug (recursively  except 57151 whose description was really long). The bug you mentioned sounds eerily similar to my problem. Although I am not using any application such as "Ultramon". I actually tested with all applications (except the anti virus) closed on a non-logitech PC. I could still reproduce the problem.
However, there is an interesting outcome. In my product, one of views has a canvas whose handle is passed on to JNI and on the C++ side the content is drawn on the control using OpenGL. Not only that, the same code is used to draw thumbnails in different editors and views also. After I closed down all views that were using this and disabled all thumbnail abilities in my editor, the problem is no longer reproducible.
I did not work on the OpenGL drawing part but I can get the developer who did it to shed some light on its implementation details. Perhaps changing something there (not hooking something) might solve our problem. Can you put forward some questions for these developers? I will invite them onto this thread.
So now, if this is the reason for my problem, can you give me some details as why this happens in SWT? What is "conflict" that is mentioned in the bugs? Is there a workaround (oh please let there be). Moving to Eclipse 3.4 or 3.5 is not going to be anytime soon for us.
Another thing that bothers me is that this does not happen on any property/preference pages or on other sash that I use in my editor. I always had this feeling that this could be because of the depth of my tree in the control hierarchy. And now that I saw your comment about depth hierarchy in 201665 I think I should print the SWT Spy output for my tree here:
Tree {}@134358
Style: SINGLE | HORIZONTAL | VERTICAL | LEFT_TO_RIGHT
Layout Data: GridData {horizontalAlignment=SWT.FILL grabExcessHorizontalSpace=true verticalAlignment=SWT.FILL grabExcessVerticalSpace=true}
Bounds: Rectangle {5, 5, 120, 368}
Children:
Peers:
*Tree {}@134358: Layout Data: GridData {horizontalAlignment=SWT.FILL grabExcessHorizontalSpace=true verticalAlignment=SWT.FILL grabExcessVerticalSpace=true}
Parent Tree:
Shell {UI - GroupsTest/root.template}@1378700
Style: RESIZE | TITLE | CLOSE | MIN | MAX | LEFT_TO_RIGHT
Layout: org.eclipse.ui.internal.layout.TrimLayout@151c5ff
LayoutData: null
Composite {}@1051158
Style: LEFT_TO_RIGHT
Layout: StackLayout {topControl=Composite {}}
LayoutData: null
Composite {}@789158
Style: LEFT_TO_RIGHT
Layout: null
LayoutData: null
Composite {}@461448
Style: LEFT_TO_RIGHT
Layout: null
LayoutData: null
Composite {}@461766
Style: LEFT_TO_RIGHT
Layout: FillLayout {type=SWT.HORIZONTAL}
LayoutData: null
Composite {}@199598
Style: LEFT_TO_RIGHT
Layout: FillLayout {type=SWT.HORIZONTAL}
LayoutData: null
CTabFolder {}@199582
Style: MULTI | BOTTOM | NO_BACKGROUND | NO_REDRAW_RESIZE | FLAT | LEFT_TO_RIGHT
Layout: org.eclipse.swt.custom.CTabFolderLayout@13dbe08
LayoutData: null
Composite {}@199580
Style: LEFT_TO_RIGHT
Layout: FillLayout {type=SWT.HORIZONTAL}
LayoutData: null
FlyoutPaletteComposite {}@199578
Style: LEFT_TO_RIGHT
Layout: null
LayoutData: null
Composite {}@199384
Style: LEFT_TO_RIGHT
Layout: GridLayout {verticalSpacing=1}
LayoutData: GridData {horizontalAlignment=SWT.FILL grabExcessHorizontalSpace=true verticalAlignment=SWT.FILL grabExcessVerticalSpace=true}
Composite {}@199342
Style: LEFT_TO_RIGHT
Layout: FillLayout {type=SWT.HORIZONTAL}
LayoutData: GridData {horizontalAlignment=SWT.FILL grabExcessHorizontalSpace=true verticalAlignment=SWT.FILL grabExcessVerticalSpace=true}
FlyoutPaletteComposite {}@134380
Style: LEFT_TO_RIGHT
Layout: null
LayoutData: org.eclipse.swt.layout.FillData@99ea5d
FlyoutPaletteComposite$PaletteComposite {}@134406
Style: LEFT_TO_RIGHT
Layout: null
LayoutData: null
FigureCanvas {}@134352
Style: HORIZONTAL | VERTICAL | NO_BACKGROUND | NO_REDRAW_RESIZE | LEFT_TO_RIGHT | DOUBLE_BUFFERED
Layout: GridLayout {marginWidth=10 marginHeight=10}
LayoutData: null
LayoutComposite {}@134354
Style: LEFT_TO_RIGHT
Layout: GridLayout {marginWidth=12 marginHeight=12 horizontalSpacing=5 verticalSpacing=10}
LayoutData: GridData {horizontalAlignment=SWT.FILL grabExcessHorizontalSpace=true verticalAlignment=SWT.FILL grabExcessVerticalSpace=true}
ClassesOutlineControl {}@134360
Style: LEFT_TO_RIGHT
Layout: GridLayout {marginWidth=10 marginHeight=10 horizontalSpacing=5}
LayoutData: GridData {horizontalAlignment=SWT.FILL grabExcessHorizontalSpace=true verticalAlignment=SWT.FILL grabExcessVerticalSpace=true}
Composite {}@134356
Style: LEFT_TO_RIGHT
Layout: GridLayout {marginWidth=5 marginHeight=5 horizontalSpacing=5 verticalSpacing=5}
LayoutData: GridData {horizontalAlignment=SWT.FILL grabExcessHorizontalSpace=true verticalAlignment=SWT.FILL grabExcessVerticalSpace=true}
|
|
|
| Re: An annoying tree control problem [message #509496 is a reply to message #509345] |
Fri, 22 January 2010 15:42 |
Grant Gayed
Messages: 2150
Registered: July 2009 |
Senior Member |
|
|
That Tree is definitely quite deep in the control hierarchy. As an
experiment, are you able to change your app to remove some of those layers
to see if it makes a difference? Also, though you said that moving up to a
recent eclipse isn't happening soon, would it be easy for you to try doing
this as an experiment (eg.- the 3.5.1 release)? If so, these experiments
should at least indicate whether you're seeing the problem that I previously
pointed you at.
Regarding the views that are using OpenGL, are you saying that it's calling
out to a C function that your app defines that uses OpenGL? If so, is there
any reason that you aren't using swt's GLCanvas class? Since showing these
views seems to be a trigger for the problem, I would suggest trying to
replace your Canvas with a GLCanvas and drawing on it from Java instead. If
the drawing that's happening in the C function is complex then just start by
drawing a few lines, which is probably good enough to determine if the
problem has been fixed or not.
HTH,
Grant
"Waqas Ilyas" <waqas.ilyas@gmail.com> wrote in message
news:hjblph$9mu$1@build.eclipse.org...
> Hi Grant,
>
> I had actually already seen the msdn page for TVM_INSERTITEM, but I
thought that someone here might have some additional clues. Apology in
advance for the long post.
>
> BTW, I am sorry I did not mention this before but I am using Eclipse
3.3.1.1 on a Windows XP machine with Nvidia Quadro NVS 290. I actually don't
have Logitech Setpoint (I think) but I do have the logitech keyboard and
mouse. I use Logitech iTouch. But this problem can also be seen on systems
with no logitech peripherals.
>
> I have done some additional testing based on your comments. I have gone
through the entire comment list of the bug you mentioned, and all other bugs
that were marked duplicate of this bug (recursively :) except 57151 whose
description was really long). The bug you mentioned sounds eerily similar to
my problem. Although I am not using any application such as "Ultramon". I
actually tested with all applications (except the anti virus) closed on a
non-logitech PC. I could still reproduce the problem.
>
> However, there is an interesting outcome. In my product, one of views has
a canvas whose handle is passed on to JNI and on the C++ side the content is
drawn on the control using OpenGL. Not only that, the same code is used to
draw thumbnails in different editors and views also. After I closed down all
views that were using this and disabled all thumbnail abilities in my
editor, the problem is no longer reproducible.
>
> I did not work on the OpenGL drawing part but I can get the developer who
did it to shed some light on its implementation details. Perhaps changing
something there (not hooking something) might solve our problem. Can you put
forward some questions for these developers? I will invite them onto this
thread.
>
> So now, if this is the reason for my problem, can you give me some details
as why this happens in SWT? What is "conflict" that is mentioned in the
bugs? Is there a workaround (oh please let there be). Moving to Eclipse 3.4
or 3.5 is not going to be anytime soon for us.
>
> Another thing that bothers me is that this does not happen on any
property/preference pages or on other sash that I use in my editor. I always
had this feeling that this could be because of the depth of my tree in the
control hierarchy. And now that I saw your comment about depth hierarchy in
201665 I think I should print the SWT Spy output for my tree here:
>
> Tree {}@134358
> Style: SINGLE | HORIZONTAL | VERTICAL | LEFT_TO_RIGHT
> Layout Data: GridData {horizontalAlignment=SWT.FILL
grabExcessHorizontalSpace=true verticalAlignment=SWT.FILL
grabExcessVerticalSpace=true}
> Bounds: Rectangle {5, 5, 120, 368}
>
>
> Children:
>
> Peers:
> *Tree {}@134358: Layout Data: GridData {horizontalAlignment=SWT.FILL
grabExcessHorizontalSpace=true verticalAlignment=SWT.FILL
grabExcessVerticalSpace=true}
>
> Parent Tree:
> Shell {UI - GroupsTest/root.template}@1378700
> Style: RESIZE | TITLE | CLOSE | MIN | MAX | LEFT_TO_RIGHT
> Layout: org.eclipse.ui.internal.layout.TrimLayout@151c5ff
> LayoutData: null
> Composite {}@1051158
> Style: LEFT_TO_RIGHT
> Layout: StackLayout {topControl=Composite {}}
> LayoutData: null
> Composite {}@789158
> Style: LEFT_TO_RIGHT
> Layout: null
> LayoutData: null
> Composite {}@461448
> Style: LEFT_TO_RIGHT
> Layout: null
> LayoutData: null
> Composite {}@461766
> Style: LEFT_TO_RIGHT
> Layout: FillLayout {type=SWT.HORIZONTAL}
> LayoutData: null
> Composite {}@199598
> Style: LEFT_TO_RIGHT
> Layout: FillLayout {type=SWT.HORIZONTAL}
> LayoutData: null
> CTabFolder {}@199582
> Style: MULTI | BOTTOM | NO_BACKGROUND | NO_REDRAW_RESIZE |
FLAT | LEFT_TO_RIGHT
> Layout: org.eclipse.swt.custom.CTabFolderLayout@13dbe08
> LayoutData: null
> Composite {}@199580
> Style: LEFT_TO_RIGHT
> Layout: FillLayout {type=SWT.HORIZONTAL}
> LayoutData: null
> FlyoutPaletteComposite {}@199578
> Style: LEFT_TO_RIGHT
> Layout: null
> LayoutData: null
> Composite {}@199384
> Style: LEFT_TO_RIGHT
> Layout: GridLayout {verticalSpacing=1}
> LayoutData: GridData {horizontalAlignment=SWT.FILL
grabExcessHorizontalSpace=true verticalAlignment=SWT.FILL
grabExcessVerticalSpace=true}
> Composite {}@199342
> Style: LEFT_TO_RIGHT
> Layout: FillLayout {type=SWT.HORIZONTAL}
> LayoutData: GridData {horizontalAlignment=SWT.FILL
grabExcessHorizontalSpace=true verticalAlignment=SWT.FILL
grabExcessVerticalSpace=true}
> FlyoutPaletteComposite {}@134380
> Style: LEFT_TO_RIGHT
> Layout: null
> LayoutData:
org.eclipse.swt.layout.FillData@99ea5d
> FlyoutPaletteComposite$PaletteComposite {}@134406
> Style: LEFT_TO_RIGHT
> Layout: null
> LayoutData: null
> FigureCanvas {}@134352
> Style: HORIZONTAL | VERTICAL | NO_BACKGROUND
| NO_REDRAW_RESIZE | LEFT_TO_RIGHT | DOUBLE_BUFFERED
> Layout: GridLayout {marginWidth=10
marginHeight=10}
> LayoutData: null
> LayoutComposite {}@134354
> Style: LEFT_TO_RIGHT
> Layout: GridLayout {marginWidth=12
marginHeight=12 horizontalSpacing=5 verticalSpacing=10}
> LayoutData: GridData
{horizontalAlignment=SWT.FILL grabExcessHorizontalSpace=true
verticalAlignment=SWT.FILL grabExcessVerticalSpace=true}
> ClassesOutlineControl {}@134360
> Style: LEFT_TO_RIGHT
> Layout: GridLayout {marginWidth=10
marginHeight=10 horizontalSpacing=5}
> LayoutData: GridData
{horizontalAlignment=SWT.FILL grabExcessHorizontalSpace=true
verticalAlignment=SWT.FILL grabExcessVerticalSpace=true}
> Composite {}@134356
> Style: LEFT_TO_RIGHT
> Layout: GridLayout {marginWidth=5
marginHeight=5 horizontalSpacing=5 verticalSpacing=5}
> LayoutData: GridData
{horizontalAlignment=SWT.FILL grabExcessHorizontalSpace=true
verticalAlignment=SWT.FILL grabExcessVerticalSpace=true}
>
|
|
| | |
Goto Forum:
Current Time: Fri Apr 19 21:40:26 GMT 2024
Powered by FUDForum. Page generated in 0.04242 seconds |
] 
Search
Help
Register
Login
Home
