Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 353131

Summary:

[DataBinding] WidgetProperties().focused() is still not updating properly

Product:

[Eclipse Project] Platform

Reporter:

Dominik Maehl <emissary>

Component:

Assignee:

Matthew Hall <qualidafial>

Status:

CLOSED WONTFIX

QA Contact:

Severity:

normal

Priority:

CC:

daniel, mallo.ovidio, ob1.eclipse, tom.schindl

Version:

3.6.2

Target Milestone:

---

Hardware:

All

OS:

All

Whiteboard:

stalebug

Bug Depends on:

Bug Blocks:

357568

Attachments:

Description	Flags
Patch	none
mylyn/context/zip	none

Description Dominik Maehl

2011-07-26 11:27:41 EDT

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).

Comment 1 Thomas Schindl

2011-07-27 11:41:53 EDT

What platform?

Comment 2 Dominik Maehl

2011-07-27 11:46:03 EDT

We've reproduced the problem on Windows XP SP2 and Windows 7 with Eclipse 3.7.0

Comment 3 Matthew Hall

2011-07-27 13:41:18 EDT

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.

Comment 4 Dominik Maehl

2011-07-28 03:35:42 EDT

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().

Comment 5 Matthew Hall

2011-09-20 02:17:36 EDT

Created attachment 203642 [details]
Patch

Dominik, does this patch fix the problem for you?

Comment 6 Matthew Hall

2011-09-20 02:17:38 EDT

Created attachment 203643 [details]
mylyn/context/zip

Comment 7 Daniel Hintze

2011-09-20 11:25:26 EDT

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?

Comment 8 Matthew Hall

2011-09-20 13:57:06 EDT

Ovidio, +1?

Comment 9 Ovidio Mallo

2011-09-20 17:00:22 EDT

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

Comment 10 Matthew Hall

2011-09-24 01:23:05 EDT

(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.

Comment 11 Lars Vogel

2019-11-27 06:59:47 EST

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.