DefaultTemplate

Developer
Jan 11, 2011 at 9:49 PM

Is there a reason the Text binding for the DefaultTemplate doesn't have the UpdateSourceTrigger=PropertyChanged property set?

Coordinator
Jan 12, 2011 at 5:31 AM

Yes, it is using the default LostFocus trigger for TextBox.Text, but I see there can be cases where you want to change this. Could you add an attribute in your model to control this, something like:

[Binding(UpdateSourceTrigger.PropertyChanged)]

Then we should update the PropertyViewModel to keep the setting, and update the template (where we get the problem to bind UpdateSourceTrigger inside the Text binding - same problem as for StringFormat...)

Or do you see better solutions? I prefer to keep LostFocus default.

I was also planning to replace the TextBoxEx with a regular TextBox and move the MoveFocusOnEnter code into a behaviour, but have not had time to do this yet.

Developer
Jan 12, 2011 at 7:29 PM

Adding such an attribute would work well. I don't realy know how to add it to the PropertyEditor though.

Developer
Jan 16, 2011 at 4:58 PM

Regarding the MoveFocusOnEnter - this is causing some very unwanted side effects in my application, and I can imagine that it can in others too.

 

The specific issue is that I'm using the PropertyEditor within an AvalonDock/DockableContent (window) and when the user press the Enterkey the focus moves from the TextBoxEx to the next control, which in my case is the DockableContent's X-button which means that when the KeyUp-event is fired (since the focus now has moved) it results in the X-being clicked and then the AvalonDock/DockableContent window closes. Not what was expected. This is on W7; on Server 2008, the behavior is different in that only the focus changes and the window remains open. Not sure why there's a difference.

 

I see three possible solutions:

1) Use the OnPreviewKeyUp instead of the OnPreviewKeyDown event to move the focus, or make the MoveFocusOnEnter behavior optional and off by default.

2) Skip the entire MoveFocusOnEnter behaviour. There's no real reason for it (the TAB-key exists for this purpose) and you can never guarantee that the next control
doesn't fire an event when it is focused, meaning that the focus-movement may have unpredictable side-effects. After all, the user is only editing/applying the values in the text box and not actively changing focus.

3) If the behavior is 'a must', then the MoveFocusOnEnter should guarantee that the focus doesn't move to a control not owned by the property editor.

Comments?

Coordinator
Jan 17, 2011 at 5:14 AM

I agree there can be undesired side-effects here, will replace the TextBoxEx with a regular TextBox (and the user must then use TAB to move to the next control). 

No solution on how to bind the UpdateSourceTrigger yet, did you think more about that one?

Developer
Jan 17, 2011 at 12:42 PM

The only thing I can think of is to have two different attributes: [AutoUpdateText()] and [LostFocusUpdateText()] or similar so that different the XAML templates can be used.

I don't see how existing bindings can be changed to allow attribute usage as you suggested.

Coordinator
Jan 19, 2011 at 7:47 AM

I have implemented the [AutoUpdateText] attribute and a new template that handles this. Will submit the code soon!

Developer
Jan 19, 2011 at 10:54 AM

Sweet :)