ok to note here that the label needs to be after the progressbar otherwise the progressbar is on top of the label

@ron In this layout you have no need for/utilize the buttonbar, so just change it to an hbox to fix the layout 🙂

no no, I like this 🙂

A buttonbar is basically an HBox with a fancy layout algo.

Haha, OK 🙂

and this is just playing with action and progress as I did not find all the information I wanted / needed

I am using an external library that does not use java..nio. I might look into getting the Path and get the outputstream from that one

I will try to look at it again. Basically, if the code inside of

runasync

finishes fast, the success handler will not even be attached by the time the call returns.

hmmz never ran into that one

Doing actual work, you never should IMO, and if you run into it, the value of wrapping that code in

runasync

is next to none. Still, it's a bug 🙂

can I know inside cellFactory which item value is associated to the cell?

when I have a TableCell and dont use enter it will delete the content from the cell which is TRASH BEHAVIOUR. trying to get around this. 🙂

@wineluis Use

cellFormat

instead and access

rowItem

🙂

rowItem

is just a front for

tableView.items[index]

@edvin don’t have the code in front of me but is ui called in the failed() case it bothers succeeded() and failed()

@edvin posted a comment to SO asking the poster to add a fail{} to rule out any application exceptions that would prevent ui{} from being called I see this all the time with new users to javafx projects

@carlw Me neither, but I think ui is only called when ut succeeds

@carlw Good point 🙂 I was a little surprised that this turned up. The last time we looked at it I think we concluded that it was hard to fix without changing the API, but that it really shouldn't bother anyone. I think even a println will delay it enough that ui would be picked up.

Every time I think about it it sounds so easy to fix.. Then I go to play with the code..

@edvin speaking of javafx, i've seen two "works as designed instances" that could explain this in the ticket. the first was my response: ui (succeeded) is NOT guaranteed to be called in the failure case. The second is stuffing Platform.runLater() calls into the runAsync (call) method and expecting them to be called before call() returns to ui(). Specifically, doing some in-process UI updates to be followed by a final UI update in the ui block

Ah, that would cause confusion for sure.

I think we just need to answer and document these cases.

a note to everyone...ALWAYS have a fail{} with your tasks

Yeah, that's a good tip. But they should be caught by the default error handler if you don't catch them, isn't that right?

yep

at least with the rest call the default error handler shows an internal webpage 🙂

explaining what is going wrong, when I was working on the imdbfx thingy I had it a lot because of time outs

Yeah, I find that it works pretty well as a default error screen in cases where I don't need to react to errors other than show it to the user. Of course for end user facing apps you'd want to present nicer or more custom error screens, but for our CRM I just go with the default in most cases.

@edvin could the inconsistency reported be related to the Platform.runLater() wrapper in the setOnSucceeded/Failed? the overridden functions are already run on the FX thread