We Keep Coding

property value overridden by parent even though set explicitly

When I have a control A that contains a control B, there are properties Prop that are inherited. That means, B.Prop will automatically take the value of A.Prop if B.Prop is not explicitly set. As far as I know, IsEnabled is such a property.
Now I have a situation where I do set the value of B.IsEnabled explicitly, and still it is overwritten by the value of A.IsEnabled. Why is that so, and how can I correct it?
In this situation A is a StackPanel and B a TextBox:
<StackPanel>
<StackPanel.Style>
<Style TargetType="StackPanel">
<Setter Property="IsEnabled" Value="True"/>
<Style.Triggers>
<DataTrigger Binding="{Binding InDisableMode}" Value="True">
<Setter Property="IsEnabled" Value="False"/>
</DataTrigger>
</Style.Triggers>
</Style>
</StackPanel.Style>
<TextBox Text="some text">
<TextBox.Style>
<Style TargetType="TextBox">
<Setter Property="IsEnabled" Value="False"/>
<Style.Triggers>
<DataTrigger Binding="{Binding InDisableMode}" Value="True">
<Setter Property="IsEnabled" Value="True"/>
</DataTrigger>
</Style.Triggers>
</Style>
</TextBox.Style>
</TextBox>
</StackPanel>
The above XAML snippet has its DataContext set to my ViewModel. The ViewModel contains a property InDisableMode which is a bool. When it is false, everything is as expected: The StackPanel is enabled and the TextBox is disabled.
But when InDisableMode is true, both the StackPanel and the TextBox are disabled although both Triggers should trigger!
Note: I know I can databind IsEnabled to InDisableMode in both controls (in the TextBox directly, in the StackPanel by using a complement converter). I have not tried if this works since I want to do this with Triggers anyway.
EDIT:
The point of disabling the StackPanel is to disable all of its children easily (except the TextBox which I want to enable instead). Any other ideas how to solve this task without changing the parent-child-relationship or creating new controls? At the moment, the only way I see is to disable all children except the TextBox one by one...

If you disable a control, its children are disabled. Since a StackPanel is not interactive, there is no reason to disable it other than to disable its interactive children.
If you want to enable a control A while its parent B is disabled, you can't do that. B cannot be the parent if you want to enable A while B is disabled.
For a workaround, you can put them both in a Grid, with the TextBox defined last, to superimpose the TextBox on top of the StackPanel. Then it will be within the StackPanel's area but it won't be a child of the StackPanel.

This happens because UIElement.IsEnabled property uses value coercion by inheriting the value from its parent. This it does by using CoerceValueCallback. Value coercion is ranked first in Dependency Property Setting Precedence List.
So, to override this behavior, we have two options. Firstly, to use AddOwner() to register our type as new owner of IsEnabled property. Secondly, to override the metadata using OverrideMetadata(). This second method would work only if you inherit directly from UIElement.
So, lets say we want our Button to behave differently, we should create a new Button like below :
public class CButton : Button
{
public static readonly DependencyProperty IsEnabled;
static CButton()
{
IsEnabled = UIElement.IsEnabledProperty.AddOwner(typeof(CButton),
new FrameworkPropertyMetadata(true, FrameworkPropertyMetadataOptions.None,
UIElement.IsEnabledProperty.DefaultMetadata.PropertyChangedCallback,
new CoerceValueCallback(IsEnabledCoerceCallback)));
}
private static object IsEnabledCoerceCallback(DependencyObject d, object baseValue)
{
return (bool) baseValue;
}
}
Here, we are returning assigned value as it is from IsEnabledCoerceCallback. Before returning, you can also introduce the behavior : If user doesn't provide any value for IsEnabled, then use inherited value from parent, else use CButton.IsEnabled user assigned value.
On a side note, try setting null in place of new CoerceValueCallback(IsEnabledCoerceCallback) , see what happens.

WPF: How to execute a command when a property on the UIElement has changed

My problem is the following:
I have a TextEdit in my view, which has a property IsKeyboardFocusWithin, which tells me if the keyboard cursor is in the TextEdit for the user to type.
On my view model I have a command which I want executed whenever the user has finished typing completely and have clicked somewhere else on the screen. That is - whenever IsKeyboardFocusWithin is set to false.
I was thinking and the only way I can think of to know when IsKeyboardFocusWithin has changed is to use a trigger in the TextEdit's style:
<MultiTrigger>
<MultiTrigger.Conditions>
<Condition Property="IsKeyboardFocusWithin" Value="False" />
<Condition Property="IsReadOnly" Value="False" />
</MultiTrigger.Conditions>
???
</MultiTrigger>
But I don't know where to place the command and have a strong suspicion I cannot.
Does anyone know if this is possible?
If not, what can you recommend I do?
The entered text is bound to a string property, and my command will do different things with it based on what it is.
Text="{Binding Path=ChatSessionName, Mode=TwoWay, UpdateSourceTrigger=PropertyChanged}"

I found the answer to my queston (pretty trivial, but I didn't see it after a long day at work).
As I suspected, Triggers were not the way to do this at all!
It turned out that my TextEdit supports an event IsKeyboardFocusWithinChanged, so what I needed to do is create a handler which called my command from the code-behind.
IsKeyboardFocusWithinChanged="TextEdit_IsKeyboardFocusWithinChanged"
private void TextEdit_IsKeyboardFocusWithinChanged(object sender, DependencyPropertyChangedEventArgs e)
{
var textEdit = sender as TextEdit;
var viewModel = DataContext as MyViewModel;
if (textEdit != null)
{
if (!textEdit.IsKeyboardFocusWithin)
{
viewModel.MyCommandExecuted(null);
}
}
}

Best practices for WPF - does every GUI element need a binding?

I am struggling to wrap my head around the real benefit of binding in WPF.
I have an application with a large textbox, designed for taking several hundred characters of user input. I have bound this to a "Text" string in my ViewModel. This works OK.
I also have a button with content "Submit". I need to change the content of this button once or twice, so I am doing it in the click event method in the window's code behind. I could, of course, bind the text to the ViewModel, but is it really worth it?
Should everything have a binding? What if I need to display a MessageBox? That will need some logic inside the onclick.
Should click events me as follows:
private void button_Login_Click(object sender, RoutedEventArgs e)
{
viewModel.DoSomething();
}
..where everything gets handed to the ViewModel?
I know this is a general question but I have tried my best to ask direct, answerable questions.

UI concerns are perfectly fine residing in your codebehind.
Business concerns should reside in your ViewModels. The commands and information they expose are what should be bound to elements in your UI.
Since changing the text in a button based on what the button is supposed to do is a UI concern, binding the text of the button to your ViewModel would be pointless.

I wouldn't put any code in codebehind. Create an ICommand property in your ViewModel and bind the buttons Command property to it. I use the ICommand implementation from MVVM Light (RelayCommand) but you can create your own or use one of the many other frameworks.
I'd then have a State property (ProcessStatus here) that I use a DataTrigger with to update the text on my button.
ViewModel
public ICommand LoginCommand
{
get
{
return new RelayCommand(() =>
{
ProcessStatus = Status.AUTHORIZING;
DoSomething();
});
}
}
private Status _processStatus;
public Status ProcessStatus
{
get { return _processStatus; }
set
{
if (value ==_processStatus)
return;
_processStatus= value;
RaisePropertyChanged("ProcessStatus");
}
}
View
<Button Command="{Binding LoginCommand}">
<Button.Style>
<Style TargetType="{x:Type Button}">
<Setter Property="Content"
Value="Submit" />
<Setter Property="IsEnabled"
Value="True" />
<Style.Triggers>
<DataTrigger Binding="{Binding ProcessStatus}"
Value="{x:Static enum:Status.AUTHORIZING}">
<Setter Property="Content"
Value="Authorizing..." />
<Setter Property="IsEnabled"
Value="False" />
</DataTrigger>
</Style.Triggers>
</Style>
</Button.Style>
</Button>

Why does a OneWayToSource binding override data triggers?

I have a WPF form with multiple controls, and I want a button ('Assign') to be enabled if and only if a variety of conditions on those controls are true. Some conditions include testing whether textboxes are empty.
I initially achieved this by binding the contents of the textboxes to properties and binding the IsEnabled property of the button in the XAML:
<TextBox Name="NewName" Text="{Binding NewName}" />
(etc)
<Button Name="Assign" ... IsEnabled="{Binding Path=AssignEnabled}" />
with a corresponding method in the C# ViewModel:
public bool AssignEnabled
{
get
{
return !string.IsNullOrWhiteSpace(this.NewName) && ... (etc)
}
set
{
...
this.NotifyPropertyChanged("AssignEnabled");
...
}
}
The problem was that this caused the button to be updated when the focus was lost from the respective textbox, not whenever the text was changed. I could have used the TextChanged property on each textbox in the XAML to call code, but this seemed overcomplicated.
To fix this, I removed the binding and switched to DataTriggers like this:
<Button Name="Assign" ... >
<Button.Style>
<Style TargetType="Button">
<Setter Property="IsEnabled" Value="True"/>
<Style.Triggers>
<MultiDataTrigger>
<MultiDataTrigger.Conditions>
<Condition Binding="{Binding IsChecked, ElementName=NewNameOption}" Value="true" />
<Condition Binding="{Binding Text, ElementName=NewName}" Value="{x:Static sys:String.Empty}" />
</MultiDataTrigger.Conditions>
<Setter Property="IsEnabled" Value="False"/>
</MultiDataTrigger>
...
(more conditions here)
...
</Style.Triggers>
</Style>
</Button.Style>
</Button>
This worked absolutely fine. The only drawback was that the unit tests I had previously written to test the IsEnabled status of the button were no longer usable (since they used the AssignEnabled property of the ViewModel which is no longer bound to the button).
To allow those unit tests to work, I needed the AssignEnabled property to reflect the IsEnabled status of the button. I expected to be able to fix this by adding a OneWayToSource binding, like this:
<Button Name="Assign" ... IsEnabled="{Binding AssignEnabled, Mode=OneWayToSource}">
with the property changed to:
public bool AssignEnabled { get; set; }
However, it seems as though this binding, even though set to OneWayToSource, overrides the DataTriggers, since the enabling/disabling of the button no longer works at all.
I know there are other options, such as using a Converter or implementing ICommand, but I would prefer to keep this simple if possible and fix the above method (or at least understand why it doesn't work). How can I access the IsEnabled property of the button without violating the ViewModel paradigm or preventing the DataTriggers from working?

You can keep your first solution and set UpdateSourceTrigger=PropertyChanged for the bindings. In this way Bindings will change instantly when text changes and not only when focus is lost. By the way this solution gives you mor flexibility as you can perform more complex testing on your fields (for exemple test email adress format).

WPF programmatically setting fields as required

I am fairly new to WPF but have spent time researching WPF validation, and have not yet seen a good approach to conditional validation.
To simplify the situation greatly, let's say I have two textboxes and a submit button. The user enters a string in the first textbox. If the user enters, for example "ABC", then the second textbox should be a required field (I'd want the background to be a light blue color, to signify this), and the submit button should be disabled until that textbox is populated.
How can this be done? Is there an easy way to add/remove validations in runtime? 'DataAnnotations' (http://msdn.microsoft.com/en-us/library/system.componentmodel.dataannotations.aspx) seemed like a good starting place, however I can't mark a field with the [Required] attribute, as the field won't always be required. Basically, I need something like 'Required if Field1 = 'ABC'
Thanks!

I would handle it using MVVM and here is a sample for that.
Implement IDataError Info on the class and that will implement two properties Error and this[string columnName] you can implement the second property with your binding errors that you want
public class MainViewModel:ViewModelBase,IDataErrorInfo
{
public string Error
{
}
public string this[string columnName]
{
get
{
string msg=nulll;
switch(columnName)
{
case "MyProperty": //that will be your binding property
//choose your validation logic
if(MyProperty==0||MyProperty==null)
msg="My Property is required";
break;
}
return msg;
}
}
Also Set ValidateOnErrors=True in binding of a textbox. here ColumnName is the name of the property that is changed and that has ValidateOnErrors set to true. Check here and put up the conditions and return message then you will see the errors on the tooltip when you put this style in your Resources.
<UserControl.Resources>
<Style TargetType="{x:Type TextBox}">
<Style.Triggers>
<Trigger Property="Validation.HasError" Value="true" >
<Setter Property="Foreground" Value="Red"/>
<Setter Property="Background" Value="MistyRose"/>
<Setter Property="BorderBrush" Value="Red"/>
<Setter Property="BorderThickness" Value="1.0"/>
<Setter Property="VerticalContentAlignment" Value="Center"/>
<Setter Property="ToolTip" Value="{Binding RelativeSource={RelativeSource Self},Path=(Validation.Errors)[0].ErrorContent}"/>
</Trigger>
</Style.Triggers>
</Style>
</UserControl.Resources>
and here is a sample of the textbox
<TextBox Text="{Binding UpdateSourceTrigger=PropertyChanged, Mode=TwoWay,
Path=PropertyName,ValidatesOnDataErrors=True}" Name="textBox1">
<Validation.ErrorTemplate>
<ControlTemplate>
</ControlTemplate>
</Validation.ErrorTemplate>
</TextBox>

I would just handle this logic in your ViewModel (assuming you're using an MVVM pattern, if not just in your code-behind).
Fire some logic on the TextChanged event for the first textbox that ultimately sets the appropriate properties. Essentially I'm saying code this validation manually. Once you start getting into more complex validation logic like this your going to start running into the limitations of the validation frameworks / declarative validation.