Cannot set button.IsEnabled=true in C# WPF

This question is as simple as it sounds. Assume button.IsEnabled == false, when I execute button.IsEnabled = true; the button remains false!! (By using the Visual Studio 'watch' feature to immediately look at the value after setting it in the debugger)

Obviously, this is not a common occurrence as generally that code works. But there is obviously something in the system that is blocking the setting and I am looking for ideas about what it could be. At first I thought it was because the button was hooked into an ICommand, which obviously controls the IsEnabled setting itself. So I eliminated the ICommand. That worked for a different button but this button is not hooked to an ICommand via "Command={Binding Path...}". In fact this button is created in C# as simply:

Button button = new Button();
button.Content = "Save Record";
button.IsTabStop = false;

These buttons exist in a Custom Control toolbar and the code which is trying to set their value occurs in a PropertyChanged eventhandler I have written. Curiously the same code initially successfully sets the button to false and that works! What could possibly be prohibiting setting IsEnabled=true?

A few hours later:

Bah, rookie mistake (after 35 years in IT). Further on down in the code was the line:

button.Command = new myCommand(...); 

So, in fact, the button was hooked up v开发者_开发知识库ia a Command Interface. I took that out and replaced it with a button click eventhandler and the problem is solved. Since I could not find this issue in Google, after numerous searches, let me restate the problem in case others encounter it: when you hook up an ICommand to a UIElement, e.g. button, menuitem, etc. .Net takes over the IsEnabled property. You can no longer set the property programmatically.

---

I know you answered this, but it looks like you just ripped out the new-style code and went back to the old way. So on the off chance that you'd like to know how the new way works, read on.

Commands are a refinement of the Event system! Commands replace the IsEnabled property and the Click event, and let you define useful shortcuts to the command.

Once you hook something up to a Command, you should no longer use IsEnabled or Click for that something.

The commanding equivalent to "IsEnabled = True" is to return True from the CanExecute event handler of the Command.

Then, define an Executed handler for the Command, and this replaces the Click event.

Why is this good? Simple: You can hook up a toolbar button, a menu item, a context menu item, and perhaps some other interface parts to the Command, and you don't have to keep track of (or define) each of those elements' Properties or events. Think of a text editor application. The traditional way would be to hook up an event to Edit > Copy, the Copy toolbar button, and a context menu item; handle the TextBox's SelectionChanged event to enable/disable all of these as appropriate; and code up the Click event for each of those. The new way is: hook the command up to Edit > Copy, the Copy toolbar button, and the context menu item, define the CanExecute event to return true/false depending on the TextBox's selection property, and code the Executed handler. Looks similar? Yes, but you declare the Command connections in markup instead of code, and you don't have to write nearly as much code. It adds up to a lot of savings when you have a lot of Commands.