Could you elaborate a bit in what scenario you need this flexibility? Just asking because every single LineEdit will now use up additional 12 bytes for the EventPublisher plus whatever the Property and it's registration map entry weigh in.

Anyway, it should be possible to create and register properties on demand, so it won't matter much.

Please upgrade the PasswordMode field in declarative.LineEdit from bool to Property.

Also you should call NewBoolProperty, instead of the generic one.

Hi, this is a very valid concern, thanks for taking a look at it.

My use case is a 'Toggle' checkbox.

Take a LineEdit side by side with a Checkbox. By default, PasswordMode is true (hide it from prying eyes let's say). If the user wants to reveal the field, he toggles.

I'm using databinding with Bind("!checkbox.Checked"), instead of:

saving the lineedit reference + checkbox reference (since event handlers don't have access to their callers) and in the state change handler checking the checkbox value then resetting the password mode.

For some reason I also have to invalidate the widget for it to rerender else I have to trigger an event (hovering for example).

You are right about adding dynamically an property, so I think if the cost is too high we can close this.

That's a legit use case.

It seems we need to call win.UpdateWindow or WindowBase.Invalidate at the end of SetPasswordMode.

Sorry, I should have been more clear. Walk should add properties on demand, not the application. It should be possible to modify WindowBase.Property to call some new factory method, if a property of the given name is not registered. Or just add the Property method to Window so it could be "overridden".