@tieskedh Must be, we haven't merged yours, have we?

@edvin the property not, I closed it

I think I'm doing something I've never done before, so I got confused.

Hang on.

Consider this object, it has an idProperty and and id var delegating to idProperty

ProductType().apply { id = 122 }

This code works fine.

But I had this code inside the compoanion object of ProductType, then it failed.

Changing to

ProductType().apply { idProperty.value = 122 }

works

I thought I had run that code before, but I must have never done it. This is a catch22 I believe.

I still need to investigate the framework itself. The only things I did untill now is changing code, where you don't need knowledge about the framework... But we it seems strange to me that it is broken after changing to range-checks...

@edvin what are your plans with reification?

or should i change somethin, before you accept it?

@tieskedh I haven't had time to review it yet.

@tieskedh What is broken after changing to change checks?

I thougt you sai i broke something, but if not nvm. About refactoring properties, just remove the inc and dec?

@tieskedh Range checks = you amended the PR to fix the issues I think. Yeah, remove inc/dec for now 🙂

I will double check and try to merge tonight.

and maybe look if providedelegate is a better alternative on the one you commented?

@tieskedh It might very well be! @pim ProvidedDelegate might be the solution to some of our KDBC issues a swell 🙂

Is there any jfoenix builders library for tornadofx?

@bsideup I think one guy started on one, but he felt that the quality of jfoenix was bad, so he gave it up.

I'm adding a RestException to TornadoFX. It will contain the exception along with both the request and the response, for better error handling. I will also add a better built in error dialog to deal with these exceptions nicely by default.

@pim That's right! 🙂 I also find their approach.. well, wrong.. They should have used skins instead of altering the component instances. That's what skins are for.

@User uploaded a file:

@edvin if we are going to use propertydelegate, we can't use readwriteproperty anymore...

So I think, we can better leave it this way... Agree or disagree?

@edvin little side node, I'm looking forward to: https://discuss.kotlinlang.org/t/implicit-interfaces-as-in-go this would be great for tornadofx!!!

@tieskedh Good catch! We'll leave it as it is then. Implicit interfaces... what use cases do you see for it?

It doesn't sound easy to implement on the JVM 🙂