Idea

TryCommitPropertyValueEdit that does not change the focus

Posted 6 months ago by Avatar Erel Uziel

The fact that TryCommitPropertyValueEdit changes the focus is very problematic. Consider this situation: the user updates an important field in one window and then clicks on a different window without pressing Enter.

The new value will not be set as the logical focus was never lost. If we now call TryCommitPropertyValueEdit then the properties grid window will become focused.

In our case it is more complicated as the grid is inside a DockSite where some of the ToolWindows are floating. Managing the active window becomes a very difficult task.

As a workaround I'm going over the visual tree, find the TextBlock and manually update its BindingExpression.


Comments (7)

Posted 6 months ago by Actipro Software Support - Cleveland, OH, USA

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?


Actipro Software Support
Posted 6 months ago by Erel Uziel

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.

Posted 6 months ago by Actipro Software Support - Cleveland, OH, USA

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.


Actipro Software Support
Posted 6 months ago by Erel Uziel

> 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.

Posted 6 months ago by Actipro Software Support - Cleveland, OH, USA

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!


Actipro Software Support
Posted 6 months ago by Erel Uziel

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.

Posted 6 months ago by Actipro Software Support - Cleveland, OH, USA

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.


Actipro Software Support
Information The latest build of this product (2018.1 build 0670) was released 4 days ago, which was after the last post in this thread.

Add a Comment

Please log in to a validated account to post comments.

Set the number of votes that you'd like to apply to this idea. You have 10 of 10 votes available.

0 supporters, with an average vote of 0.00.