Home » Eclipse Projects » Standard Widget Toolkit (SWT) » Curious behavior disposing a child widget... it reappears!
| Curious behavior disposing a child widget... it reappears! [message #437610] |
Tue, 08 June 2004 20:21  |
Eclipse User |
|
|
|
Originally posted by: swt.cloudnine.net.nz
Hello, I've had a look the forums but could not find anything related to
this problem, so I thought I'd ask...
I'm using Eclipse M9 SWT and JFace jars, linux 2.6 and of course, GTK2.
I'm seeing some quite curious behavior when disposing a child of a
Composite. The dispose works (for example, I have 5 children before I
begin disposing, and 0 afterward), but I have another thread that
refreshes the same composite, and when it performs a getChildren(), it
still sees 5 child objects.
Looking at the SWT code, I can see that _getChildren() makes a (in this
case) GTK call, and receives a 'list' handle. This handle is different
every time the GTK call is made (and the _getChildren() call also 'frees'
that list). I'm assuming that this is a temporary handle to a in-memory
list created by GTK (I know next to nothing ... OK, nothing ... about GTK
internals). It seems that this list does reflect the change when the
remove() method is called, but doesn't reflect the change at the time the
refresh() method is called.
Some further information about the environment might be useful.
I'm trying to show/hide a dialog box with "request" (as in, 'please
do task X for me') information in it. The user may be sitting at their
screen with the GUI, and requests will come in via JMS. The JMS handler
code will makes syncExec()ed calls against the GUI to add and remove
elements from it (debug code shows that this is working. e.g:
before the 'remove' call I have 5 children (in the grid), and after, I
have zero).
There is another thread, that is started when the GUI starts. It sits
there and performs a syncExec()ed .refresh() against the composite that
contains the children, in order to update one of the fields (a 'time left
until request is automatically canceled Label).
It's this refresh() method that is showing the 'weirdness'. That is,
log4j stmts are showing that 5 children still exist when the refresh()
method is called - even though this happens (in time) after the remove()
method is called on that object.
I'm using syncExec() against the default display in all cases.
I don't understand what's going on here. On one hand, some code running
in the GUI thread can make calls against GTK and observe a visible
reduction in the number of child objects in a Composite. But then, we see
some other code (same GUI thread, but syncExec()ed from the 'refresh'
thread) shows that the Composite in question still has 5 children.
The effect of all of this is that a user presses OK on one of the
requests, the 'remove' method removes all of the child components (so that
the request info disappears from the GUI), and a split second later,
those 5 child widgets reappear.
Anyone got any tips?
I'm more than happy to post code, but didn't want to just yet because this
message is long enough as it is!
Regards,
Neil Clayton
|
|
|
| Re: Curious behavior disposing a child widget... it reappears! [message #437846 is a reply to message #437610] |
Thu, 10 June 2004 23:18  |
 Daniel Spiewak
Messages: 263
Registered: July 2009 |
Senior Member |
|
|
Try it on a couple other platforms. If you don't have access, then post
the code. I'll be happy to try it on MacOS X 10.2 and Windows XP as
well as my copy of Fedora Core 1. Otherwise, it sounds like a bug in
the native code.
Daniel
Neil Clayton wrote:
>Hello, I've had a look the forums but could not find anything related to
>this problem, so I thought I'd ask...
>
>I'm using Eclipse M9 SWT and JFace jars, linux 2.6 and of course, GTK2.
>
>I'm seeing some quite curious behavior when disposing a child of a
>Composite. The dispose works (for example, I have 5 children before I
>begin disposing, and 0 afterward), but I have another thread that
>refreshes the same composite, and when it performs a getChildren(), it
>still sees 5 child objects.
>
>Looking at the SWT code, I can see that _getChildren() makes a (in this
>case) GTK call, and receives a 'list' handle. This handle is different
>every time the GTK call is made (and the _getChildren() call also 'frees'
>that list). I'm assuming that this is a temporary handle to a in-memory
>list created by GTK (I know next to nothing ... OK, nothing ... about GTK
>internals). It seems that this list does reflect the change when the
>remove() method is called, but doesn't reflect the change at the time the
>refresh() method is called.
>
>Some further information about the environment might be useful.
>I'm trying to show/hide a dialog box with "request" (as in, 'please
>do task X for me') information in it. The user may be sitting at their
>screen with the GUI, and requests will come in via JMS. The JMS handler
>code will makes syncExec()ed calls against the GUI to add and remove
>elements from it (debug code shows that this is working. e.g:
>before the 'remove' call I have 5 children (in the grid), and after, I
>have zero).
>
>There is another thread, that is started when the GUI starts. It sits
>there and performs a syncExec()ed .refresh() against the composite that
>contains the children, in order to update one of the fields (a 'time left
>until request is automatically canceled Label).
>
>It's this refresh() method that is showing the 'weirdness'. That is,
>log4j stmts are showing that 5 children still exist when the refresh()
>method is called - even though this happens (in time) after the remove()
>method is called on that object.
>
>I'm using syncExec() against the default display in all cases.
>
>I don't understand what's going on here. On one hand, some code running
>in the GUI thread can make calls against GTK and observe a visible
>reduction in the number of child objects in a Composite. But then, we see
>some other code (same GUI thread, but syncExec()ed from the 'refresh'
>thread) shows that the Composite in question still has 5 children.
>
>The effect of all of this is that a user presses OK on one of the
>requests, the 'remove' method removes all of the child components (so that
>the request info disappears from the GUI), and a split second later,
>those 5 child widgets reappear.
>
>Anyone got any tips?
>I'm more than happy to post code, but didn't want to just yet because this
>message is long enough as it is!
>
>Regards,
>Neil Clayton
>
>
>
>
|
|
|
Goto Forum:
Current Time: Fri Apr 26 17:33:50 GMT 2024
Powered by FUDForum. Page generated in 0.02441 seconds |
] 
Search
Help
Register
Login
Home
