@edvin np

@carlw Thanks, that means a lot. I hate leaving everybody hanging, especially when I see there are some questions unanswered here 🙂 The new structure Thomas has proposed for the guide will make it much easier to add a Wiki style chapter to the guide, so that we can start answering things a single time, and just improve upon the answers when they need elaboration.

@thomasnield I love the new layout, go ahead and merge if you have the time 🙂

@edvin I think the only unanswered questions are @Ruckus 's preferences SO and @aayush 's ControlsFX auto complete

@carlw Thanks, I will answer the preferences question after I've helped Alyssa with some homework 🙂

(@carlw Not my question, I just saw it's been sitting for a couple days and don't have time to answer right now, so I threw it on here hoping someone else could.)

understood...just providing an identifier for those scanning the channel

i probably should have read over the post and made sure it wasn't a "how do I set a type safe style" before attributing it to you

Preferences are actually described OK in the Wiki, we just need someone to move it from the Wiki to the new structure after @thomasnield has pushed his restructuring 🙂

@devanand commented on @carlw’s file https://kotlinlang.slack.com/files/U25U0KPFT/F7977CQ5U/custom_key_event_filter_on_tableview_cellfactory.kt: Navigation worked, but two binding is not working any more

@devanand can you try, temporarily, replacing the event filter with a println() statement and see if the event filter -- consume() in particular -- is interfering with something?

tried commenting the consume(),same result.

are you getting a binding exception or is the binding not saving the value?

Hey @jelloranger good that you figured it out and sorry that we are all so busy and not answering as quickly as usual 😉... Regarding your code snippet you can clean it up even a bit more. You can use the togglegroup builder instead of creating the instance by your self. Then there is no need to reference the toggelGroup manually anymore the builder is doing that for you. And last but not least you can introduce a object property which will represent the currently selected Enum value which is done by the

bind

function. For demo purposes i just put the toggleProperty to the top most of the time you will probably put the property in the corresponding view model. Hop this helps 😉

Hi all. I have a question concerning the ItemViewModel. When I use the bind method, the value that is return should be Property<T>. When using null values and an objects, that I created, the value becomes Property<SimpleObjectProperty<T?>> in the IVM. Here is an example is below. I set the initial value of Token to null. When using the token value in UserModel, the type of token becomes Property<SimpleObjectProperty<Token?>> instead of Property<Token?>. When I remove nullability from token in User--token becomes Property<Token>. My question: is this intended?

@bkenn uploaded a file: Untitled

@bkenn The null (?) interferes with type inference to match the javafx.beans.property.Property<N> parameter used in some of the bind methods. Your token is calling a fallback called bindField that will wrap up the type that is missing details for reification into a JavaFX Property. The following snippet illustrates this.

@carlw uploaded a file: Can't Reified Infer with the Null Assignment

@bkenn Can you do something like this if you don't have a Token yet? You can validate against the empty jwtString. class User(username: String,firstName: String, token: Token = Token("")) {}

If there are any mechanical keyboard fans near Frankfurt, there's a meetup on October 14th https://www.reddit.com/r/MechanicalKeyboards/comments/6w07jq/news_frankfurt_germany_meetup_on_october_14th/ ⌨️

@nimakro Thanks for the PR for Fragment support for TreeView. It looks great. Let me know when I should merge 🙂

The next feature I'd like to add is

rowFormat

for Table/TreeTable/Tree.

@bkenn There is something wrong here for sure. We had a major refactoring of properties support a while back, this looks broken to me. I will look into it ASAP, but probably not before Java One.

@tieskedh I wonder if this happened during the PR. Haven't confirmed yet, but this looks fishy 🙂

@bkenn In the mean time, you can define your property as

val tokenProperty = SimpleObjectProperty<Token>(token)

if that's acceptable. That should create a more sensible binding property 🙂

@tieskedh I've never really used nullable properties, so this might not be because of the PR, maybe we never supported them.

@edvin which PR did you initially think caust this problem?

@tieskedh I would have to check, didn't we reorganize the bind function slightly?

Maybe I'm confusing your PR with another one.

don't remember so, but I have to go to school. My deadline is suspended, but I still have a lot of work to do. You coul of course add another bind-function for properties that already are properties to unwap and wrap them again... But I have no time today anymore...