@carlw Thanks... I think I remember now trying that in the past, I had forgotten....

I'm no expert on javafx, but is there a reason that we arre using SwingUtilities.invokelater instead of platform.runlater?

@tieskedh Where? invokeLater is only good for interacting with Swing/AWT. It's used some places in the framework where we access AWT features like the tray.

@User uploaded a file:

@edvin I think for @pike 's problem regarding setting params for multiple openModal() calls, the problem is that the params object in Component is not refreshed in the find() function. On the first call, inheritScopeHolder's map is set and that's the basis for the params object in Component (View superclass). On the second call, the inheritScopeHolder's map is updated however, params does not get updated with the new stringKeyedMap

@User uploaded a file: Untitled

I'll put an issue in

@carlw That sounds right. Thank you!

i think the answer is to keep the reference rather than making new stringKeyedMap

I'll be able to look at it tonight. @dr.fornax still looking at the combobox problem but am stuck on the server-side all day today

@edvin That's a neat keycap. Spin the cube to press a key? you may bring the 60% down to 10 keys with that innovation

@carlw Thank you!

@carlw Yeah, will write some firmware for the cube tonight. I need something to do.

Or maybe I'll just rehearse my talk 🙂

@edvin stefan had a few things to look at. i've been looking at setting the button cell on an editable combobox. his dynamic contacts project works for me if i turn editable off. I have some examples where I work with the button cell in a combo box for an auto complete but have to sanitize them

OK! Sorry that I'm not able to follow up right now. Thanks for picking up the slack!

NP. i can create a PR tonight. do you think something like this would work? i see it's ThreadLocal storage but that everything is single threaded with Views

PR Candidate? @edvin

There's a chance of collisions because this is a global object shared by all the views

Would doing something with the returned cmp instance (Component:429) be better? Maybe overlay the find() input params directly onto the params object of cmp?

Yeah, this isn't very good design. We need a better solution for sure. I will try to look at it tonight and figure out why I did what I did.

maybe take a step back and look at the spec for the params object in find() (ex does it parameterize for just the most recent find call?) and see if it needs to influence the properties object on the View (Component) side of if something else can be done

like a constructor arg of Map

I think I rememeber that the parameters has to be available for the View at construction time. That was part of the issue.

But it sounds like this could be solved with a threadlocal, handled inside of find. Maybe that's what it is.

@edvin I think the global nature of params should be looked at. I created a second View with a similar onDock. I call it with openModal() and no parameters. This second View is able to get at the first View's parameters (the one called w. params in openModal).

so, for general parameter passing, i don't think it's suitable. you either have to do your own name mangling (ex, "tornadofx.myproperty") or worry about confusion, say two Views trying to "pass" a property called "id".

This code, if called after a similar find() w. params, will use those params rather than put() new ! and @ ones

@edvin What about using a generated convention to organize params in properties? In the Component.kt file, you will look at the properties stored with the View (Component) and remove all of those starting with "tornadofx.param" and replace them with those coming in from the find() call. (maybe best done in openModal() if find() is supposed to not modify the instances)

I'm sure there must be even simpler solutions to this.