no the file (test.kdbx) contains information about login information for websites (for example) the entry is a object representing that

so it is not a file I am dragging but an entry

@carlw Yes. It would add some complexity, but it would be slightly faster. Fixing.

not looking for faster...IMHO there's still a boundary case because runLater isn't guaranteed to be run right away, only before the next runLater

setOnAction { val t = FXTask... t.setOnSucceeded( { doSomething() } ) t.start() }

I'm suggesting something like this. pardon the kotlin pseudocode

@edvin uploaded a file: Untitled

@carlw That can't be done without breaking the API, and there is no chance for the new implementation to fail.

that looks good to me. line 13 takes care of the boundary case where you're already on the fx thread and don't want to defer

what happens if the state is neither SUCCEEDED nor RUNNING?

@carlw commented on @ron’s file https://kotlinlang.slack.com/files/U14ECM2KV/F8DPXSXMK/-.kt: It's actually Koninklijk Eepass @ron

@amanda.hinchman-dominguez commented on @ron’s file https://kotlinlang.slack.com/files/U14ECM2KV/F8DPXSXMK/-.kt: I see - I'll read into this!

@carlw @ron ran into some reported issues from clients on production, I'll be right back

@carlw If it's not succeeded and not running means that it ended with a non-successful outcome, and the function shouldn't be run.

@carlw Please challenge my statement, I'm often wrong on such logical issues 🙂

me too...bear with me... for call(), you pass in a block of code that is delegated from the Task call. for success() and fail, you pass in a block of code and then attach the successHandler. if you are in the creation phase, that code won't be called right away because it's neither running nor succeeded...is this how the code is working with the latest fix? runAsync { // all this goes into the call() implementation } success { // 1. attach handler (assuming event thread) // 2. not running, so setOnSucceeded isn't called }

You have a point here, let me think for a second..

good. because I'm getting dizzy

@carlw If there is congestion or some sort of backlog, you could end up in a state where it's not running yet at this stage.

The safe thing to do is to always attach the listener and remove the else if

Damned, I already poured myself a glass of whisky and patted myself on the back.

is it committed? i can pull it down later

Yes, will fix and do another commit now.

We could expand the check instead though, hang on.

i think we can assume for now that the task() Thread is running by the time we get to the apply()?

maybe i'm just obsessing over a potential gap between Thread.start and the next method (setOnSucceeded)

@carlw Thread running is not the same as that the task has transitioned to the running state.

@carlw There could potentially be several seconds before a task transitions to the running state

I blew a fuse, back now 🙂

sorry