@edvin Is there a problem with the TornadoFX examples working with data classes? I seem to have to put mine in javabeans-style form to get the syntax errors to go away

@carlw - thanks - heading out for the evening - will look at it in the morning 🙂

@carlw Right now it's actually impossible.

runAsync

returns a

Task

, but it doesn't operate in the context of that task. It should be easy enough to change it though, let me try.

@carlw I feel that the API is better with the change, but it breaks the API if somebody referred to

this

inside

runAsync

@edvin what do you do for progress bars?

While a long running task is active you mean? I've mostly used

runAsyncWithProgress

, but it doesn't show a progress bar, just a progress indicator that you have no real control over.

I've used the raw Task from JavaFX for progress bars it seems.

I'm trying to change the API to see how much if anything it breaks in my existing apps.

runAsync

would need a type parameter for many cases, unless we let it operate on

Task<*>

. Then you'd have access to all functions of the task, just not the type. Don't know if you'd need to.

@edvin Can you chuck the snippet I pinned into a file and let me know what you think? I use this pattern all the time outside of TornadoFX

you can hit my “service” because it’s just a file

Hang on, got to complete this task thing.

@permalmberg Nice, you're getting the hang of it now!

@carlw What was the issue you had with data classes? What syntax errors?

Sure. I learned that it’s best to use updateMessage() and updateProgress()…I tried many times to put in Platform.runLater() blocks or event-firing or UI control. Often, those seemed to result in Platform.runNever()

@edvin for the data classes…it might be the way I set them up. When I walk through one of your examples with a Person class, it doesn’t take the one-liners that I’m used to writing

@carlw I had one single breaking issue in a pretty large program with the

runAsync

change (

this

is the task). We could avoid breaking anything if

it

is the task, but I like it better with

this

. Not sure what to do..

The "fix" was to remove

this

from

this.id

🙂

@carlw And I just realized,

updateProgress

is protected, so it cannot be run from outside the task. Would need to create some kind of task adapter for it.

@edvin i think it’s worthwhile pursuing this. task(func()) is going to miss out on being able to report the in progress feedback to the user.

@edvin I’ve faced this problem before, but had to abandon supplementing func() with embedded FX calls because of the aforementioned “never calling” problem. I would write a sequence of statements - logic/runLater/logic/runLater - and the runLaters would never be called.

@edvin but updateProgress/updateMessage/succeeded worked fine

OK, trying an alternative approach now.

Interesting.. it seems that by combining inline functions, reified generics and removing the inline flag from the function parameter it might be able to avoid giving the type parameter for the

runAsync

call, but still infer it, and still be able to get to it from both inside and outside the task.

Too tired. Will try again tomorrow 🙂

np. talk to you tomorrow. i’m going to type up the example I posted for @gtnarg as a demo of MVVM with TornadoFX

Great! Good night 🙂

@carlw I like this format 🙂 Hope I didn't mess up. I think I didn't understand the reason for how you did the event handling etc, so this might require a follow up to explain better 🙂 You know design patterns much better than I do.

I run the chance of embarrassing myself when I jump into something like this, but heck.. it's worth it 🙂