[tlhIn`toq]

So am I blind or stupid?

I have two IntegerUpDown controls on a window. They are each bound to properties on the code behind cs file. Those are interacting with a class of R & D testing property values, which gets serialized and deserialized as a means of save and load.

Here's the problem, one works and is interactive with its bound property and one isn't. I know it has to be something I'm overlooking but I sure can't see it.

If you change the value on the IntegerUpDown for IterationGap and the value propagates through all the files/classes. It saves/load correctly; restoring when you relaunch the application. IterationCount does NOT restore at launch. It does not change with the GUI.

But if you change values on the IterationCount IntegerUpDown control there is no stop at the breakpoints for those properties.

So it seems it would have to be a mistake/difference in the binding on the WPF window XAML, right? Seems like a "duh" situation. But they look the same to me:

If one was wrong, then the IDE would bring it to my attention, so it *must* be doing the binding, right?

This is the serialed RandDobj with the values

Does anyone see a difference between how these two controls and corresponding properties are coded/implemented that would cause this difference in behavior? Or have any other clue what would cause it?

[tlhIn`toq]

UPDATE:

I've tried several variants on this, changing how the data context was assigned to by-pass the code-behind properties even. Still no joy.

Then I stripped all the binding assignments to concentrate on just making 1 or two work.

Then just working on 1: The IterationCount updown control that isn't working. As a test I assigned the IterationGap property to the IterationCount control - to see if the problem was in the control or in the property. The control accepted the binding.

It lets me manipulate the Gap property. So it isn't the GUI control itself.

It has something to do with the PROPERTY I'm trying to use. But I still can't figure out what.

[tlhIn`toq]

Next step:

Its not a problem with doing more than one binding on the Window, because I can bind the two IntegerUpDown controls to the same 'good' property and they react in tandem like one would expect.

[tlhIn`toq]

Well… It sure seems to have been some sort of corruption someplace I wouldn’t even begin to know where to look. After creating a new UserControl and copy/pasting all the original XAML, creating a new settings class and slowly copy/pasting all the original code into that everything works. At this point everything in the new controls and classes is a complete copy/paste from the broken ones. The broken ones have been removed and their references updated to point to the new ones… and everything works. Time to backup seven ways from Sunday.