abbaye / WpfHexEditorControl

Wpf Hexeditor is a powerful and fully customisable user control for editing file or stream as hexadecimal, decimal and binary. Can be used in Wpf or WinForm application
https://www.nuget.org/packages/WPFHexaEditor/
Apache License 2.0
815 stars 136 forks source link

Binding attached to the read only mode property is detached after changing it's value #133

Open Filipsi opened 1 year ago

Filipsi commented 1 year ago

Describe the bug There is a problem when changing value of ReadOnlyMode property trough one-way binding like this:

<wpfHexaEditor:HexEditor
    FileName="{Binding SelectedFile}"
    ReadOnlyMode="{Binding IsReadOnly}" />

When binding changes the property, the value is then internally set to a explicit value and the binding gets detached - which makes it impossible to be changed again. You can see what happens in the trace log - the binding changes property from default false to true, after which it is detached.

This worked fine until WpfHexEditor version 2.1.3 and seems to be broken since then.

This can also be verified when using Scoop to debug the control.

before after

To Reproduce I have created a simple test application, since your showcase does not use bindings. Build can be found in the releases alongside with the test files.

Steps to reproduce the behavior:

  1. Open the test application.
  2. Click on Open file button
  3. Select A or B text file
  4. Try changing bytes
  5. Click on the Read only button
  6. Try changing bytes, you cannot
  7. Click on the Read only button again
  8. You still can't change bytes, even though read only mode is disabled

If you are compiling the test application yourself, you can see the trace log in the output when debugging. You can also try to change editor version to 2.1.3 and try the same test, this will work as expected.

Expected behavior It should be possible to control ReadOnlyMode of the editor trough one-way binding.

Remarks From what I can tell, you are changing property values from inside the control using SetValue that replaces the value with a new one. But in this case, should probably be using SetCurrentValue method that changes the effective value of the property, but keeps existing triggers, data bindings, and styles so they will continue to work.

More about this can be found in this blog post.

I suspect there will be more problems like this with other properties that are been changed from inside of the control.

Configuration