Community
Participate
Working Groups
Build Identifier: 20110615-0604 We've encountered the problem already described and (I'm afraid) not fixed in Bug 294810. We've narrowed down the problem and it seems, as if on a SWT.FocusOut event isFocusControl() still returns true. This leads to IObservableValue.getValue() returning a true when its actually false. I don't know if this is a problem with the point in time on which SWT.FocusOut is fired or if it has to do with DataBinding. We've hacked around this problem by implementing a state into the ControlFocusedProperty which is initially set and afterwards changes its value to false on SWT.FocusOut and to true on SWT.FocusIn. Reproducible: Always Steps to Reproduce: 1. Run the Snippet which is attached to bug 294810. 2. Click inside the text field. 3. Switch to another window 4. The checkbox does not change its state Note: Do not click on the unused space in the same window as it belongs to the checkbox and disables it directly (not through databinding).
What platform?
We've reproduced the problem on Windows XP SP2 and Windows 7 with Eclipse 3.7.0
One possible workaround until this is fixed is to use WidgetProperties.focused().observeDelayed(widget, delay) with a very small delay (e.g. 0 or 1ms). Since it appears that the FocusOut event is sent just *before* the control loses focus, this delay will ensure that an event is not fired until just *after* focus is lost.
The workaround does not work. I assume this has to do with observeDelayed() behaviour when the widget loses focus as the javadoc states "...which delays notification of value changes until at least delay milliseconds have elapsed since that last change event, or until a FocusOut event is received from the widget (whichever happens first)." So it essentially seems to trigger evaluation of the property at the same time as it would be triggered without observeDelayed().
Created attachment 203642 [details] Patch Dominik, does this patch fix the problem for you?
Created attachment 203643 [details] mylyn/context/zip
The patch does indeed fix the problem for us. Thank you! (Dominik is on vacation right now) (In reply to comment #5) > Dominik, does this patch fix the problem for you?
Ovidio, +1?
Maybe we should make a "if (!event.widget.isDisposed()) { ... }" check inside the asyncExec's run method. I think it's always a good idea when you do something asynchronously. Also, you might want to add a reference to the bug to the file header. Beside that, +1
(In reply to comment #9) > Maybe we should make a "if (!event.widget.isDisposed()) { ... }" check inside > the asyncExec's run method. > Also, you might want to add a reference to the bug to > the file header. Agreed on both points. I'll rework the patch.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. If the bug is still relevant, please remove the stalebug whiteboard tag.
