Oh sweet!

@edvin - I'd rather get a 1.0.6 release if that's possible?

@gtnarg Will do!

@gtnarg 1.0.6 is released, will hit Maven Central within the hour 🙂

@edvin - much appreciated 🙂

@gtnarg I'm just happy that you keep a little oversight over the controls project :))

@edvin the succeeded() method of Task does run on the UI thread

can't you just override it or are you redefining your own in #514?

Not sure if you're familiar with the "double-check locking pattern" but this is looking like a "double-check fx thread pattern"

@carlw It does? I can't find the code that guarantees this, but I thought that was the case myself..

It's in the docs for Task

(plus 5 years of experience)

Maybe take a step back and untangle the runLater() calls?

@carlw The runLater call needs to be there, because you must call

setOnSucceeded

on the UI thread. But then everything should be OK, shouldn't it?

i think everything in those methods (succeeded, failed, cancelled) is driven off of properties. if you start supporting non-FX thread stuff i think you'll run into problems with property objects

there's stuff like this already in the cancel method of Task

if (isFxApplicationThread()) { 972 setState(State.CANCELLED); 973 } else { 974 runLater(new Runnable() { 975 @Override public void More ...run() { 976 setState(State.CANCELLED); 977 } 978 }); 979 } 980 }

(from javafx.concurrent.Task.java)

@edvin here's why you don't want to get too aggressive with runLater() even though it's "safe". On my Ubuntu system w. 152, this prints "second" before "first"

Output:

doing something me second me first

@edvin for #514, maybe we should hear more about the use case. IMHO, i'd keep the tornadofx API in line with the javafx docs. ex, don't make "success" run off the UI thread and go against the docs. there are a lot of plain Java threading constructs that don't involve JavaFX if the OP wants to keep stuff off the JavaFX thread

@carlw There are no surprises in your code examples. Maybe we're talking past each other, we're not talking about allowing success to run on another thread than the ui thread, just enforce it. I thought it was already enforced, but the op suggests that it's not, right? I suspect it might work as it should and something else is causing the issue he's seeing though.

@edvin i'm looking at the OP's last comment "success run on calling thread and ui on UI thread"

@amanda.hinchman-dominguez uploaded a file:

The files probably aren't in an /img directory off of your drive root. Try this. since you're keeping the files (for now) mixed in with your source, move them to a folder under main called resources/img. You should have src/main/kotlin and src/main/resources

In intelliJ, be sure to go into your project setup and flag this folder (resources) as a resources folder. that way, they'll get moved to your generated classes folder where they'll be put in your classpath

next, pull off the file:/ part of your listOf

The listOf elements should be of the form "/img/Metro.png"

ah, thank you! I didn't realize IntelliJ works differently when working with resources.