@edvin I thought I'd need to create a custom

cellFactory

but the

cellFormat

appears to be setting it to a new one

@edvin I'll try creating a custom one, I just found some docs 😉

That's right, cellFormat is basically a super easy way to create a cellFactory without all the boiler plate. It's called whenever the

updateItem

call for the cell is called. So you can either bind there, using

cleanBind

or you can use a

cellFragment

if you have lots of logic in the cell code.

No need to create a custom cell, that's almost never the best thing to do i TornadoFX.

oh - that sounds a lot cleaner

If you use a cellFragment, you need to consider that when the Fragment is created, you don't have access to any data. You only have an

itemProperty

which will be null at creation time. To deal with that, wrap an ItemViewModel around the

itemProperty

and bind towards the view model properties. That's really clean, but you need to understand it properly.

I've seen several people go the

cellFragment

route but fail to realize that you don't have any data when the Fragment is created. Once you master it, it's really convenient. That being said, if you don't have lots of logic, just bind in

cellFormat

.

Is it considered good practice to unbind after usage or before, or both?

I have never used a

Fragment

before, I'll see if it works now 😉

@dr.fornax Sorry that I didn't write back this morning.. This is how you could use the GoogleMaps in TornadoFX. I just created a builder which creates an GoogleMapsView instance. You could also add more builders so you don't need this big initialized block. But I think this gives you an idea on how to integrate an external control

@pim You'd use

cleanBind

, which unbinds before it rebinds, basically.

@edvin I'm getting a RTE now, will post the code

@User uploaded a file: Untitled

When the property is modified elsewhere, it throws an error saying 'A bound value cannot be set'.

@pim The other way around,

textProperty().cleanBind(nameable.nameProperty)

Still throws

Forgive me for being extremely new to JavaFX 😓

We love you for it 🙂 hehe

Really like when people skip learning JavaFX and goes straight to TornadoFX. It's absolutely doable, and we've tried to write the guide in such a way that it should be possible.

Will try to create a sample for you. The problem is that my pizza just arrived 😁 😎

Maybe I should give some more background info.. The data is being modified somewhere else, to test the auto updating UI. Like this:

item.nameProperty.value += " 123"

@edvin I just realized while playing with a

FilteredList

that it make a difference if I do

private val testList = listOf("test1", "test2", "test3", "blub1", "blub2").observable()

private val testList = FXCollections.observableArrayList("test1", "test2", "test3", "blub1", "blub2")

the first one will throw an

UnsupportedOperationException

if you call

setAll(...)

since it is using

ObservableListWrapper

which is not implementing the

setAll

function 😀🙈

TreeCell.updateItem

appears to be called with a

null

item and

empty=true

, while in fact it is not -> this causes a RTE because I bound the

textProperty

and the method is setting

text

to null.

@pim Yeah if you add an

textProperty().unbind()

it works. @edvin Should we add

textProperty().unbind()

and

graphicProperty().unbind()

to the cellFormatter?

@pim This is basically the example for a

TreeView

from the tornadoFx guide, and I added a

textfield

and a

button

if you select a person you can change the name and with save the name will be committed and therefor visible in the

treeview

. I implemented the cellfactory my self since the default implementation (

cellformatter

) is not unbinding the

textProperty

when set to null like you pointed out before.

But maybe @edvin has an even cleaner approach? We will see😀

@nimakro Wow, thanks for your effort! It seems like the default implementation should do this though? I'll wait for @edvin to share his opinion I suppose 🙂

My recording session was cut short because of some issues with the recording server, so I'll have a look now 🙂

That's indeed a bug. It is specified correctly for TableView, but not TreeView. Committing a fix now!