choice.onChange { if (it.equals("A")) { formA.set(true) formB.set(false) } else { formA.set(false) formB.set(true) } }

let me post something. you don't want to do that. (use binding instead)

🙂

var formA = SimpleBooleanProperty(false) var formB = SimpleBooleanProperty(false) var choice = SimpleStringProperty() override val root = form { fieldset("?") { field("?") { combobox(choice, FXCollections.observableArrayList("A","B")) } field("1") { textfield() removeWhen { formA } }.isDisable = true field("2") { textfield() removeWhen { formB } } field("3") { textfield() } } choice.onChange { if (it.equals("A")) { formA.set(true) formB.set(false) } else { formA.set(false) formB.set(true) } } }

was my test bed

@sp33dy The key is the form*Flag.bind statements. I would use an Enum and a special renderer in the ComboBox rather than the duplicated String (ex "Form A") as a good programming practice but don't want to muddy the waters.

@Spike Baylor In the apps I work on, there's always an impedance between what's persisted, say in a JSON file, and what you see on the screen. In a lot of the code that we sling around here, there's usually a one-to-one correspondence between the UI controls and the data fields such that we tend to collapse any trivial objects. So, i usually have that plain Kotlin-only layer and a bridging object that's property oriented

There are some good examples with the REST api where there's little boiler plate. but if you have to unpack say a result set, you might go into something javafx oriented

@carlw so it sounds like for my case i am more or less doing the right thing? its all working, have a nice tree type model, with a simplified tfx viewmodel representation tied to a treetable that all updates great. Just wasnt sure if that was how things woupd get done since all of the tutorials and examples are so trivial.

as far as tradeoffs go, the tornadofx-ness of the solution is less important to me than avoiding a maintenance drag of boilerplate or trivial code

Sorry, had to go to a client meeting

that source code looks much better! Thank you. As for the enums, I couldn't find a way to pass the enum into the combobox

it was something I just couldn't get to work, without writing a piece of code to loop around and create a list

i'll add in the enum bit later. this isn't tornadofx specific but it's a bad idea to refer to the strings like i did. if you want a quick fix, create some global constants at the top of the file const val FORMA = "Form A"

the enums require a different renderer for the ChoiceBox. that's so you won't display a Java identifier like Form_A

yes, been using const 🙂

get what you are saying

the bind is magic!

makes everything really easy to read

getting combobox to take an enum would be heavenly

it's the key to make a decent UI. been through too many Swing listeners. converted a few Swing apps to JavaFX and the business logic that accrued was formidable

Feels odd throwing away SO MUCH code

I can't believe how sweet this is

yeah. i used to write command line tools for small client tasks. now i can deliver a UI . the customers are MUCH happier since they don't want to run cmd.exe

Exactly where I am

I used to huff and give them large estimates, as I didn't want to create the GUI. I'm now quite excited to do so

@sp33dy Here is an (overengineered) example of using enums in ComboBox:

-.kt

If you want to render something else than the name of the enum, you'd add a

cellFormat

callback which derives the text you want, for example like this:

@edvin oh thanks. I'll start to digest it. This gives me everything I need (I believe) to move my client app; using the DragNDrop example to boot