Issue-Import-Test about rico

[hendrikebbers]

Comment by hendrikebbers
Friday Feb 05, 2016 at 10:29 GMT

---

I don't know if we need a setting. Why not always check if we are in the Platform thread and otherwise do a invokeAndWait

[hendrikebbers]

Comment by aalmiray
Friday Feb 05, 2016 at 10:42 GMT

---

Because JavaFX does not have an equivalent to invokeAndWait. Well it does, but it's behind a private API that we shouldn't use 😏
What we need is Platform.runLater if not already inside the UI thread.

[hendrikebbers]

Comment by hendrikebbers
Friday Feb 05, 2016 at 11:57 GMT

---

I don’t know if runLater is enough. Let’s say a property is set in a background thread. By doing so JFX property will be updated by invokeLater. But maybe the JFX property is bound bidirectional to more than 1 property. By doing so you can end in strange behavior. Example:

dpProperty1;
dpProperty2;
jfxProperty;

FXBinder.bind(jfxProperty).bidirectinalTo(dpProeprty1);
FXBinder.bind(jfxProperty).bidirectinalTo(dpProeprty1);

In external thread call:

dpProperty1.set(„Hello“);
dpProperty2.set(„World“);
System.out.print(dpProperty2);

By doing so the first line will call an update of the Property by using InvokeLater. Than the second one will be executed and again the update will be triggered by using invokeLater. Let’s say the first invokeLater is handled between line 2 and 3. By doing so line 3 will print „Hello“ instead of „World“. That’s why I would like to use a invokeAndWait. Creating this method for JFX is quite simple.
2 years ago I asked Richard Bair why invokeAndWait is not part of the public API. He told me that people that don’t know how to handle it will use it in a wrong / bad way but if you know how to handle it you can simply create it on your own. I think we are part of the second group and therefore should use it ;)

Am 05.02.2016 um 11:42 schrieb Andres Almiray [email protected]:

Because JavaFX does not have an equivalent to invokeAndWait. Well it does, but it's behind a private API that we shouldn't use
What we need is Platform.runLater if not already inside the UI thread.

—
Reply to this email directly or view it on GitHub https://github.com/canoo/dolphin-platform/issues/77#issuecomment-180289702.

[hendrikebbers]

Comment by netopyr
Friday Feb 05, 2016 at 12:37 GMT

---

I am afraid, I consider myself in the first group. ;)

Setting a property can cause change listeners to be fired. You have no idea and control over what happens in these listeners, thus wrapping property.set() in an invokeAndWait() seems like a bad idea.

[hendrikebbers]

Comment by hendrikebbers
Friday Feb 05, 2016 at 12:51 GMT

---

@netopyr can you give a short example what could go wrong? Currently I see no problem and want to understand it

[hendrikebbers]

Comment by netopyr
Friday Feb 05, 2016 at 13:23 GMT

---

If I understand your idea correctly, you want to wrap a call of the setter of a JavaFX property in an invokeAndWait-block, right? It is a JavaFX property, which means a user can attach any kind of change-listener to it. I could for example create a dead-lock by doing something that waits for the thread that called the setter in the first place.

As a rule of thumb I would never block anything, if I do not have full control over what is going to happen during the block and even if I have full control, I would try to avoid it.

[hendrikebbers]

Comment by aalmiray
Friday Feb 05, 2016 at 14:12 GMT

---

No,no. This should be done with invokeLatersemantics, waiting would be overkill. Also, it only makes sense for now to protect the flow of data between DP property and JavaFX property, not the other way around, even in a bidirectional binding scenario.

[hendrikebbers]

Comment by hendrikebbers
Friday Feb 05, 2016 at 14:13 GMT

---

Ok :)

[hendrikebbers]

Comment by hendrikebbers
Friday Feb 05, 2016 at 14:15 GMT

---

Then this should be quite easy since we already have the UIThreadHandler instance in the config.

[hendrikebbers]

Comment by hendrikebbers
Wednesday Feb 17, 2016 at 23:50 GMT

---

So the final plan is to call an invokeLater (by using UIThreadHandler) for setting the JFX property based on a change in the DP property, right?

[hendrikebbers]

Comment by aalmiray
Thursday Feb 18, 2016 at 08:13 GMT

---

Yes, although I'd prefer a smarter version of invokeLater:

• if already running inside UI thread -> execute
• else post event using runLater

[hendrikebbers]

Comment by netopyr
Thursday Feb 18, 2016 at 08:39 GMT

---

+1
The binding should behave synchronously if we are already on the right thread, because it makes it much easier to understand the simple case.

[hendrikebbers]

Comment by hendrikebbers
Thursday Feb 18, 2016 at 10:38 GMT

---

ok