i may put in a commit to fix an issue with completing items while the active filter is on

but i'll check in with your changes later when you're feeling better

Ok, sweet. What I'm seeing right now is that each cell correctly gets their own fragment, but all labels/checkboxes/textfields are bound to the value of the last TodoItem added. Extremely weird 🙂

yeah. i think i mentioned a destructor before (which was my misrecollection of Kotlin de-STRUCTURE-ing) that could clean up the listeners and other references

@carlw I must be doing something completely wrong, because this shouldn't happen, since rebinding is performed. There is something weird with the itemProperty inherited from ListCellFragment I think.

@edvin i'll trace the program later. i think this has been around since the ListCellFragment, it just wasn't noticeable with my updateLabel() call because that wasn't state-changing and could be called multiple times without throwing off the totals

@edvin now that i'm trying to keep the # of completed clicks 100% in sync with the model, this is surfacing

@edvin do you think there might be a leak with the new fragment class?

Did something change with the guide? I used to go to the main page and click on read. There was a table of contents and a search bar (which is my main entry point). Now it just takes me into the book - no table of contents or search bar...

@gtnarg I'll verify

@carlw Yes, I'm pretty sure it has to do with the new fragment class. Found two bugs there already 🙂

My programming has been completely off lately, need to get my head back in the game.

@edvin if you need me to help test something, send along a patch or get a test case going in tornadofx

@carlw Thank you Carl. I'm still very pressed for time, finishing up the cabin project and tons of stuff at work that has been piling up while I was away, so I just need to get my bearings 🙂

@edvin np. i can run a little ScenicView and count up the instances too

@carlw I don't want to waste your time. I have some fixes in, and I'll squash this last bug and let you know so you can do something more productive with your time 🙂

@edvin someday it'll be wasting my time, but now i like to look over your kotlin code and lookup stuff in the wiki about reified types or extensions

@carlw I did a reimplementation of TodoItemFragment without looking at the old code. That worked perfectly. I think I must stop looking for a bug in the framework and rather identify the difference between the original version and my reimplementation. I first did an ultra small implementation with a builder and then changed to FXML when I couldn't reproduce the error anymore, and it's still good with the FXML version. Will keep digging and let you know what I find 🙂

@carlw I committed a fix for the bugs in the

ListCellFragment

btw 🙂

@carlw Ah, finally. It has to do with the

bind

function in TornadoFX. It works fine when I do

contentLabel.textProperty().bind(item.textProperty)

but fails when I do

contentLabel.bind(item.textProperty)

@edvin that's what i mean about learning reified types and extension functions

@edvin i should put a small weight on my Control key for the left clicks

Dang, I wonder what this is all about. Need to say hello to the wife as well, but I'll solve it tomorrow, I'm sure 🙂

To make it more interesting there seem to be a debugger issue with IntelliJ, so I have to resort to println statements to figure this out. Of course 🙂

It is not the

bind

function per se, but something goes wrong with bidirectional bindings..

@carlw I figured it out, and it's all about unbinding bidirectional bindings. I just can't understand why this hasn't bitten me/us a lot more earlier. It seems that you need to make sure to unbind everything before rebinding inside a Cell, and that totally makes sense, but I'm amazed that I haven't stumbled upon this before. The following code works, but is not a good solution of course:

@User uploaded a file: Untitled

One way to avoid this would be to re-introduce a ViewModel, so that there is a one-to-one relationship between ViewModels and Cells. Then when the itemProperty changes, the rebinding would occur only in the ViewModel (the binding towards the UI Nodes would remain). The issue we had last time was with changing the underlying data without notifying the ViewModel. This is a interesting issue to figure out 🙂

This could be solved by introducing a new mode to ViewModel bindings: If the underlying observable change, the change is automatically pushed to the ViewModel. I actually think this should be the default when you bind to observable values.

Maybe this was the first time tornado was tracking each and every call. My earlier version of the todo could fire the listener multiple times without a problem.