Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
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 Go to next message
Waqas Ilyas is currently offline Waqas IlyasFriend
Messages: 40
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 #508358 is a reply to message #508336] Mon, 18 January 2010 14:42 Go to previous messageGo to next message
Waqas Ilyas is currently offline Waqas IlyasFriend
Messages: 40
Registered: July 2009
Member
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 #508615 is a reply to message #508358] Tue, 19 January 2010 11:12 Go to previous messageGo to next message
Grant Gayed is currently offline Grant GayedFriend
Messages: 2151
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 #508836 is a reply to message #508336] Wed, 20 January 2010 14:12 Go to previous messageGo to next message
Waqas Ilyas is currently offline Waqas IlyasFriend
Messages: 40
Registered: July 2009
Member
Thanks for the reply.

As I said I get resize events when the tree goes into error state. Under these events I have checked that whenever the tree goes into error state (by checking that tree.getItemCount() == 0) I called OS.GetLastError() before and after attempting to create an item. But every time it returns 0.

Is there any set of reasons as to why ERROR_ITEM_NOT_ADDED would occur? Although this is not the real problem here, but it still might give us some clues.

I will try to isolate the problem even more and will get back to you.
Re: An annoying tree control problem [message #508838 is a reply to message #508336] Wed, 20 January 2010 14:17 Go to previous messageGo to next message
Waqas Ilyas is currently offline Waqas IlyasFriend
Messages: 40
Registered: July 2009
Member
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 #508884 is a reply to message #508838] Wed, 20 January 2010 16:05 Go to previous messageGo to next message
Grant Gayed is currently offline Grant GayedFriend
Messages: 2151
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 Go to previous messageGo to next message
Waqas Ilyas is currently offline Waqas IlyasFriend
Messages: 40
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 Smile 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 Go to previous messageGo to next message
Grant Gayed is currently offline Grant GayedFriend
Messages: 2151
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}
>
Re: An annoying tree control problem [message #509764 is a reply to message #508336] Mon, 25 January 2010 10:39 Go to previous messageGo to next message
Waqas Ilyas is currently offline Waqas IlyasFriend
Messages: 40
Registered: July 2009
Member
Hi Grant,

I can try reducing the hierarchy but experimenting a move to 3.5.1 might not be easy for me. We have a large code base and using a lot different frameworks (EMF, GEF etc. and third party libraries). So I shall keep this as the last resort.

Drawing on the Java side is not an option for us. We have an engine that basically draws on the Canvas and it has to be through JNI. The engine is actually an embedded runtime that we have ported to provide a deployment time "preview" in our application on the host machine. Would GLCanvas still be a useful option here?

I will get back to you with some more findings.
Re: An annoying tree control problem [message #509844 is a reply to message #509764] Mon, 25 January 2010 15:13 Go to previous message
Grant Gayed is currently offline Grant GayedFriend
Messages: 2151
Registered: July 2009
Senior Member
You can try swapping in GLCanvas for Canvas. At the native level it will
still be the same type of control, but GLCanvas does some GL-specific setup
up-front. I'm not sure if it will make a difference, but it's easy to try.

Grant


"Waqas Ilyas" <waqas.ilyas@gmail.com> wrote in message
news:hjjscq$j7q$1@build.eclipse.org...
> Hi Grant,
>
> I can try reducing the hierarchy but experimenting a move to 3.5.1 might
not be easy for me. We have a large code base and using a lot different
frameworks (EMF, GEF etc. and third party libraries). So I shall keep this
as the last resort.
>
> Drawing on the Java side is not an option for us. We have an engine that
basically draws on the Canvas and it has to be through JNI. The engine is
actually an embedded runtime that we have ported to provide a deployment
time "preview" in our application on the host machine. Would GLCanvas still
be a useful option here?
>
> I will get back to you with some more findings.
Previous Topic:Table: Removing not only items, but also all colums
Next Topic:Selection in Text and mouse events
Goto Forum:
  


Current Time: Sun Dec 21 07:04:40 GMT 2014

Powered by FUDForum. Page generated in 0.19093 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software