TryCommitPropertyValueEdit that does not change the focus

Hi Erel,

A problem with trying to commit a value is that each control type used as a property editor (TextBox, ComboBox, one of our part edit boxes, etc.) all have different core bindings that we'd need to handle in separate ways.  Whereas a focus change always kicks in the binding, regardless of value editor control tryp.

I wonder if we should do something like we have with PropertyGrid.CancelPropertyValueEditHandlers where we make something like a CommitPropertyValueEditHandlers and pre-define some for common control types.  Then regardless of if one of those is defined or not, if the focus is currently within a PropertyGridItem but not on the PropertyGridItem itself, still allow the focus move.  That would allow the focus to be placed back on the row item when you press Enter, but would probably not move focus in your scenario where you already focused somewhere else before calling TryCommitPropertyValueEdit.  In your case, is Keyboard.FocusedElement outside of the property grid when you call TryCommitPropertyValueEdit?

What are your thoughts on the above?

In our case the commit related issues only happen with TextBoxes. This is the only place where the user sees a value different than the already set value.

Allowing to easily commit TextBoxes will probably solve most or all of the need to call commit.

> In your case, is Keyboard.FocusedElement outside of the property grid when you call TryCommitPropertyValueEdit?

Yes. For example I want to commit the field when the user clicks on a different tool window.

Hi Erel,

We've made a couple updates for the next build:

• Added the PropertyGrid.CommitPropertyValueEditHandlers collection that allows for customization on how Enter keys are handled for various property editor types.
• Refactored PropertyGridItem.TryCommitPropertyValueEdit to only focus the itself if focus was within it

That should prevent the focus move. 

Although after looking at the implementation, calling TryCommitPropertyValueEdit() when the actual property editor doesn't ahve focus will effectively do nothing.  That method is only effective when the focus is within a property editor since it needs to know which control currently has focus so it can examine it, get a binding, and update the source.  That being said, if your click to focus elsewhere already moved focus, focus moves always commit bindings.  So you should be ok.

> That being said, if your click to focus elsewhere already moved focus, focus moves always commit bindings. So you should be ok.

Not always. If the user clicks on a different window then the value is not committed (based on my tests). This also happens if the user clicks on a floating tool, which I guess is treated as a different window.

Hi Erel,

Can you mock up a brand new very simple sample showing the two scenarios you described and send that to our support address?  We will debug with that and see what we can do to help.  Reference this thread in your email.  Please remove any bin/obj folders that are in the ZIP and rename the .zip file extension so it doesn't get spam blocked.  Thanks!

Open PropertyGridPropertyEvents example. Change the LastName field and switch to a differnet window (different program in this case). The value is not committed.

If you called TryCommitPropertyValueEdit from the second window then the focus would have switched back to the first window.

Anyway, this is just a suggestion. The workaround I've implemented works properly in our program.

Hi Erel,

I did some testing and it appears that bindings in WPF will not update if focus moves to another Window.  They only update if focus moves to another control in the same Window.  That explains why the PropertyGrid element bindings weren't updating in this scenario.

Knowing that's how WPF works, we were able to do some tricky stuff to improve TryCommitPropertyValueEdit.  We made it a public method and added logic that helps with the scenario where focus is outside of the PropertyGrid.  These updates will be in the next build and should help with your scenario. 

If you'd like to test a preview build, please write our support address and reference this thread.