I've bound the visibility of some buttons to a bool, but when the bool changes, the button's visibility does not change. Why could this be?
The boolean is set up as such:
public static readonly DependencyProperty editModeToggle = DependencyProperty.Register("editMode", typeof(bool), typeof(Window));
public bool EditMode
{
get { return(bool)GetValue(editModeToggle); }
set { SetValue(editModeToggle, value); }
}
I'm pretty sure the binding isn't at fault.
[Note: I have set up a Converter that works and the binding works. The visibility just doesn't change when I change from true to false or vice versa]
Binding:
<Button Content="Test" Visibility="{Binding ElementName=mainWindow, Path=EditMode, Converter={StaticResource BooltoVisibilityConverter}/>
There are a few things you need to check when a binding does not work as expected:
Does the bool property notify change using
INotifyPropertyChanged?
Do you use a converter to convert from
bool to Visibility?
Do you see any binding errors in output
window?
Have you tried putting a breakpoint on binding in xaml
or setter in bool property?
As you have mentioned in your comment, you have not implemented INotifyPropertyChanged interface.
The need to implement the interface is whenever value of the property in ViewModel changes, there has be be a way for binding to know that. So, after implementing INotifyPropertyChanged, for each property, you raise the PropertyChanged event with the property name in it. That way, the binding knows that value of the property has changed.
There are lots of articles online. Here is one to get you started: INotifyPropertyChanged and WPF
Dependency Property registration is not correct -
public static readonly DependencyProperty editModeToggle =
DependencyProperty.Register("editMode", typeof(bool), typeof(Window));
It should be-
public static readonly DependencyProperty editModeToggle =
DependencyProperty.Register("EditMode", typeof(bool), typeof(Window));
Notice the spelling of property - 'E' should be capital since its case sensitive and your property name is EditMode not editMode.
In this case you don't need point 1 from decyclone list since you are using a dependency property. I think that you should add Mode=TwoWay in binding if you don't have it, that will solve it.
Related
I don't understand the interest of a dependency property without callback defined.
A callback is just an added convenience -- dependency properties are integrated into the framework runtime, and have a built-in callback mechanism that updates any bindings. That is, if you set a binding with a dependency property as the source, then the target will update automatically when the dependency property changes.
For example, let's say you have a custom control with a DP defined:
public string SomeDP
{
get { return (string)GetValue(SomeDPProperty); }
set { SetValue(SomeDPProperty, value); }
}
public static readonly DependencyProperty SomeDPProperty =
DependencyProperty.Register("SomeDP", typeof(string), typeof(SomeFrameworkElement), new PropertyMetadata(null));
And if you set up a binding with the DP as the source for a TextBlock's "Text" property:
<local:SomeFrameworkElement x:Name="someFrameworkElement" SomeDP="initial" />
<TextBlock Text="{Binding ElementName=someFrameworkElement,Path=SomeDP}" />
Then whenever "someFrameworkElement"'s "SomeDP" property changes, the text will also change.
New to WPF. I am creating UserControls that need read access to the ViewModel state to do their thing. I currently use the following technique:
public partial class ControlBar : UserControl
{
private static readonly DependencyProperty URLProperty =
DependencyProperty.Register("URL", typeof(string), typeof(ControlBar),
new UIPropertyMetadata(null));
public ControlBar()
{
InitializeComponent();
SetBinding(URLProperty, "CurrentPage.URL");
Pin.Click += Pin_Click;
}
private void Pin_Click(object sender, RoutedEventArgs e)
{
var URL = (string)GetValue(URLProperty);
}
}
Is this the correct way and is it not overkill to set up a long-term binding for each variable I need access to? Or can you do something like:
GetValue(new Path("CurrentPage.URL.....
I made up the above obviously.
Thanks!
In general data-binding is the way to go. However sometimes when you are creating controls that have view-specific concerns for which data-binding will not be appropriate.
In those cases you will want to be able to interact with the DependencyProperty to set it and know when it changes. I have been following a pattern that I picked up from a Charles Petzold article in MSDN magazine.
My answer to another question shows the pattern for creating a DependencyProperty for a UserControl Stack Overflow: Dependency Property In WPF/SilverLight
Again, data-binding to a view model will likely solve your problem, but a DependencyProperty may come in useful depending on the situation.
Update in response to comment:
In many situations you can data bind your in a UserControl without using a DependencyProperty. For example if you have a TextBlock that displays a name you would put a TextBlock in the XAML of the UserControl
<TextBlock Text="{Binding Path=NameString}" />
In the view model which is present in the DataContext you would have a property NameString and if the TextBlock is to update the display when the NameString property changes the view model should implement INotifyPropertyChanged and the property should fire the PropertyChanged event with the name of the property sent along with the event.
protected string _NameString;
public string NameString
{
get { return _NameString; }
set { _NameString = value: Notify("NameString"); }
}
Where Notify is a method that checks the PropertyChanged event for null and sends the event if not null.
This works well if everywhere that you want to use the UserControl has a view model with a Name property. The great thing is that the UserControl can pick up on the DataContext of wherever it is hosted and bind to an external view model.
When you want to start binding the same UserControl to different properties is one place that you may want to use a DependencyProperty. In that case you could make a UserControl with a DependencyProperty and bind it to different properties
<my:SampleControl NameString="{Binding Path=GivenName}" />
<my:SampleControl NameString="{Binding Path=FamilyName}" />
And then have an internal view model that the DependencyProperty change handler updates when the bound property changes.
Update: No DependencyProperty or binding
You can always add an ordinary C# property to the UserControl and pass the data in that way.
public MyClass Data { get; set; }
Then in the code-behind of the UserControl you can simply use the property:
if (this.Data != null)
{
this.textBox1.Text = Data.NameString;
}
Update in response to comment:
Another way to access the view model in code is to cast the DataContext to your view model type:
MyClass data = this.DataContext as MyClass;
if (data != null)
{
// do something
this.textBox1.Text = data.NameString;
}
We can achieve the binding by simply CLR property, so why do we need to use DP?
When do you need DPs over CLRPs?
When you need binding
when you need property value change callback (Default Implementation)
When you need property value validation
When you need animation
When you need property value inheritance
When you need to attach a property value to another element (Attached Property, but still)
When you need styling
Some of these can be implemented in CLR properties. But, with DPs, its piece of cake.
Typically these are declared in UserControls and derived controls.
You can bind to a CLR property, but you can't bind with a CLR property; you'll need a dependency property to do any binding.
Edit (in response to comment)
Let's say you need a TextBox, but you want to customize it to have different behaviour in "EditMode" and "ReadMode". You'll need to either create a derived class or a UserControl; in either case you'll add a DependencyPropery.
public class TextBoxWithModes : TextBox
{
public bool EditMode
{
get { return (bool) GetValue(EditModeProperty); }
set { SetValue(EditModeProperty, value); }
}
public static readonly DependencyProperty EditModeProperty = DependencyProperty.Register(
"EditMode", typeof (bool), typeof (TextBoxWithModes));
}
With this in place, you can declare it in XAML:
<Namespace:TextBoxWithModes Text="enter text here"
Width="200"
HorizontalAlignment="Center"
EditMode="{Binding IsChecked, ElementName=editModeCheckBox}" />
I have this DependencyProperty:
public bool ShowEntireHierarchyEx
{
get { return (bool)GetValue(ShowEntireHierarchyExProperty); }
set { SetValue(ShowEntireHierarchyExProperty, value); }
}
public static readonly DependencyProperty ShowEntireHierarchyExProperty =
DependencyProperty.Register("ShowEntireHierarchyEx", typeof(bool), typeof(CustomizeStatisticsStyleControl), new UIPropertyMetadata(false));
And I'm binding it to this CheckBox in XAML:
<CheckBox Margin="16,5,0,0" x:Name="checkBoxHierarcy"
IsChecked="{Binding ElementName=customizeStatisticsStyle, Path=ShowEntireHierarchyEx, Mode=TwoWay}">
S_how entire gate hierarchy
</CheckBox>
But for some reason the CheckBox does not change the ShowEntireHierarchy property, but if the ShowEntireHierarchy property changes in code, the CheckBox does change. What am I missing here?
Thanks!
The reason SetValue is not being called is that dependency property bindings do NOT go through the CLR setter. A bound DP is updated "behind the scenes" by WPF, i.e. directly in a private "slot" managed by the DP system.
It's therefore probable that your DP is being set when the check box changes. The setter breakpoint not being hit shouldn't concern you. You should only worry if you have some other reason to believe that the DP is not being updated.
To break on changes in a bound DP, add a PropertyChangedCallback in your property metadata, and set a breakpoint in that callback.
We have an object that derives from DependencyObject, and implements some DependencyProperties.
Basically something like this:
class Context : DependencyObject {
public static readonly DependencyProperty NameProperty =
DependencyProperty.Register ("Name", typeof (string), typeof (Context), new PropertyMetadata (""));
public string Name {
get {
return (string)this.GetValue (NameProperty);
}
set {
this.SetValue (NameProperty, value);
}
}
}
This works, the property is setup, can be bound, etc. The issue comes when I bind TO the propery from WPF, using a TwoWay bind. The TwoWay part never actually happens, WPF never calls the set of this property. I have set my binding up like this:
<TextBox Text="{Binding Path=Name, Mode=TwoWay, UpdateSourceTrigger=PropertyChanged}" />
In this case, typing in the text box should immediately update the Name property, but it does not. If I change the Name property to be a regular POCO property, it works (though the other side of the TwoWay obviously doesn't unless I implement INotifyPropertyChanged).
What am I doing wrong here? This should be a really simple thing to do, but it's causing me no end of headaches.
This is expected behavior. The CLR property is merely a wrapper around the underlying DependencyProperty. WPF often optimizes by calling GetValue and SetValue directly. If you need custom logic to execute then use the metadata of the DependencyProperty.
After this issue cost me some time:
For those of you who have the same problem, but - like me - don't see the solution in the answer above:
To support inheritance of the DataContext, the custom class (Context in this case) has to be derived from FrameworkElement rather than DependencyObject. That's all.
Marc