I have re-encountered this bug and forgot the cause more than once

I should remember by now

BTW, I use this syntax which I think came from @tieskedh fun main(args: Array<String>) { launch<MyApp>(args) }

@carlw oh cool, good to know

If you're using Kotlin 3.1, you can shorten it to

fun main() = launch<MyApp>()

(assuming you don't care about the

args

)

What about passing named parameters to a Scope with that string-object map - is that deprecated or something?? I can't find thsi in the docs, just in that one stackoverflow post.

@thomasnield what was the problem with smartResize? i think you should use a factory instead of putting node creation in the domain object

is that repeat/threadlocal thing your particular randomness algorithm for whatever you're doing?

smartresize often flickers weirdly for me, while I resize the window...

@carlw What I'm doing is using an Rx

Observable<Node>

that feeds into a

Binding

which feeds into the

TableView

factory.

smartResize definitely does some weird stuff 😞

That

Node

is formatted heavily with conditional formatting and other stuff

I could try to use

cellFormat

and

cellDecorator

, but the frequency of changes due to user interaction makes them misbehave quite a bit.

Yeah...

smartResize()

and other resizing mechanisms are useful for 95% of TableViews in my experience. But when you get into highly customized TableViews with a bunch of Nodes for cells... it breaks down

hey guys, does anybody have suggestions as to how to synchronize (read: suspend until completion of) on

fun initialize() = launch {...

style controller initializers?

@thomasnield this puts the random requirement in a button action. it could be launched from an onShow too

I wish that - given a map of parameters p - there was a way to recognize if a Fragment/View is already in a scope, and • if the Fragment does not exist, then create it with these parameter • if the Fragment does exist, then let it consume the parameters somehow

application: 1. Some view (rsp. Fragment) that displays a collection of images, which it takes as parameter (or alternatively is injected via model, whatever). 2. If you open it once, the observable list of images passed to it is used directly. 3. If you try to open it again, it just focuses the one that is already open, and adds the list of images passed as argument (or model via scope) to the existing list of images.

Views are singleton so you can make a shared controller or viewmodel available to get data supporting the screen. Fragments are prototype scope so as soon as you're finished, they go away. There are a lot of samples that inject Fragments into a singleton View so they seem singleton-ish themselves.

So, maybe re-opening a Fragment ought to be a View.

I want the user to be able to override the open-only-once behaviour though

you're saving the result of a find() ?

saving?

what is meant by saving here?

i am at some point storing the result of a find in some map - if that is waht you mean?

the find() on the fragments are in the builders for the scene graph?

mm - not sure waht you mean. so im using find to get to the fragment instances of course, as I should in the framework -

then I actually wrap them and send them over the eventbus, and the receiving main windows opens them in a tab pane

by adding them

Its an editor application with several different types of tabs