though not sure if that's expected behavior or a side effect of whatever tornadofx does internally with https://github.com/edvin/tornadofx/blob/master/src/main/java/tornadofx/Component.kt#L89

Here's a note from @edvin on the subject (recommending scopes) https://github.com/edvin/tornadofx/issues/731

This has some more options from him https://stackoverflow.com/questions/41198155/tornadofx-how-to-pass-parameter-to-fragment-on-every-instance

All the variation comes from a design goal to keep TornadoFX as flexible as possible, regardless of software architecture

Here's a blast-from-the-past with us discussing params versus ViewModels https://github.com/edvin/tornadofx/issues/443

</end>

I'm implementing a Wizard but the flow not serial. Depending on what the user selects on the first page, I might want "Next" to navigate to a one page, or another page if they make another selection. Is there any support for this?

This is a quick test I did, but it works

@gtnarg I've done a few things like this, but not in TornadoFX. What do you think about storing an object that contains the Wizard transitions paired with a set of predictates? The ordering of the added Views and the predicates determine the Next order. I was also thinking that this object would record its navigation as bread crumbs and that the Back order would be determined by the established path. I did this on a survey application once. The app was adaptive in that the exact survey questions weren't known in advance but going back over the survey wasn't supposed to produce whole new flows. There was always the option to completely start over.

@gtnarg I'm curious, is it possible to dock multiple times?

Also - interesting implementation I noticed: scaling down an image for

imageview

keeps the same original space needed for the full size, which shoves everything to make room unnecessarily. I might just force the area to have the intended width/height and worst case scenario I'll create a stackpane but that would be a dumb reason to implement another component

@gtnarg if you could dock multiple times with fragments, you wouldn't have to worry about passing scopes for every sequential view..... that's my theory at least

A file was commented on

@amanda.hinchman-dominguez uploaded a file:

@carlw - I was hoping to reuse the TornadoFx wizard functionality as much as possible but will keep this in mind

@amanda.hinchman-dominguez - there is one shared scope for the wizard (available to all pages) - I just need to be able to dynamically change the flow of pages vs. having a fixed sequence - I have some good ideas to proceed a bit further now...

just discovered the snippets portion of the documentation. async lazy loading might be the way to go

whoops, that just covers loading. Doesn't solve the shoving issue.

@mikehearn You should always use find, even for Fragments. You would still get dependency injection if you just created the fragment, but some life cycle methods would be skipped, so you might miss dock/undock and other callbacks.

@edvin i wonder if there's a way to do it such that parameters can be passed in a more idiomatic way than a variant map

When I start editing a table cell and I scroll on the table, sometimes the cell stops editing and sometimes the editing cell duplicates a few cells bellow, is there any way to fix this? (I am not sure this is a TornadoFX bug but who knows) https://gyazo.com/adfe79b47424e5ef2764d43d0b1e7703

Also, I am using a custom

CellFactory

, if that is relevant, but I believe it is not the cause

@mikehearn Yeah, I don't really like the way parameters are passed. I try to stay away from parameters all together, but they are convenient in some cases. What would be a nicer interface?

@SackCastellon Try it with a plain JavaFX app to see if you can trigger the same bug. If not, post the complete code and we'll look at it.

i guess what i wanted to do (code is written now) is figure out the best way to model a chunk of UI, like a custom control but without the hassle of making a full blown javafx custom control

(which isn't that well documented imo.... at least not in java 8)

so to do that OOP is great, but you want to be able to customise it e.g. via c'tor params

it seems like this is a very common task

@mikehearn in that case, wouldn’t you just create a builder helper like the rest of the API? Ex customControl() versus find(<CustomControl::class>)?

perhaps that's the way to go, yes.