EntityState - RangeConstraintMode

I am using an IntegerTextBox with its Value bound to a property on an EntityObject.  When I set the IntegerTextBox.RangeConstraintMode to OnLostFocus I encounter a problem.  Now whenever I remove focus from the IntegerTextBox my EntityObject's EntityState gets set to Modified even if no changes were made.  I only noticed this because I visually present the EntityState so the user can know when they need to commit changes.  Do you have any straight forwards ways to address this problem?

Here are a few more details about the setup.

<ms:IntegerTextBox Style="{StaticResource styleIntegerTextBox}"
                   Minimum="0" Maximum="65535"
                   Value="{Binding Path=Core.ForwardPort, FallbackValue=6769}" />
                  
The style is defined as:

    <Style x:Key="styleIntegerTextBox" >
      <Setter Property="ms:IntegerTextBox.BorderThickness" Value="1"/>
      <Setter Property="ms:IntegerTextBox.Height" Value="19"/>
      <Setter Property="ms:IntegerTextBox.Background" Value="{DynamicResource {x:Static SystemColors.WindowBrushKey}}"/>
      <Setter Property="ms:IntegerTextBox.RangeConstraintMode" Value="OnLostFocus"/>
      <Setter Property="ms:IntegerTextBox.IsTabStop" Value="False"/>
    </Style>

Thanks,
Roy

Thanks for drawing our attention to this.  Ideally, we'd recommend that this be fixed in the Port setter implementation, which should be marking the EntityObject as modified only if the value is actually changing.  That is, the set implementation should have a guard around it, something like this:

public int Port {
  set {
    if (value != Port) {
      // existing setter code goes here
    }
  }
}

The reason for recommending this is that it avoids spurious changes to the Modified state no matter where they come from -- our controls, other controls or application code.  The semantics of Modified are presumably that some value has changed, not just that someone has invoked a property setter.  It's better to enforce that within the setter than rely on all controls and application code being well-behaved.

That said, we clearly shouldn't be updating the bound property unnecessarily.  So I've implemented a fix in the next nightly build of WPF Elements (available from about 1200 GMT), so that you'll no longer get the vacuous setter calls.  So even if you are not able to update the setter implementation, you should no longer see spurious changes into Modified, at least from our controls!

As always, if you still see the problem after updating to the nightly build, let us know!