If you look at Selector and TabItem classes they apparently both own the IsSelectedProperty.
static Selector()
{
...
IsSelectedProperty = DependencyProperty.RegisterAttached("IsSelected", typeof(bool), typeof(Selector), ...);
...
}
static TabItem()
{
IsSelectedProperty = Selector.IsSelectedProperty.AddOwner(typeof(TabItem), ...);
...
}
So I guess my question is... since the Tabitem contains the actual propertychanged logic, what is the point of the IsSelectedProperty even residing in the Selector class?
In this specific case, Selector has the IsSelected DP because there are a number of controls that derive from it whose items can be selected (ComboBox, ListBox, ListView, TabControl, DataGrid). They all need an ability to mark an item with IsSelected, therefore that DP is declared in their common base class. Like Tim said, DRY.
Another reason that TabItem adds itself as an owner is that in the Selector class, IsSelected is an attached property because you can have just about anything as an item in a Selector. Attached properties are pretty mobile that way.
However, TabItem adds itself as an owner such that it is not an attached property on TabItem. It also registers a callback method to be called when the value changes so that it can do a few things when selected or unselected.
And yes, it is easier to type <TabItem and see IsSelected in Intellisense rather than going, "But how the heck do I make one selected?" and have to hunt around and find that you need to use an attached property from some other class.
It's basically just an instance of DRY (Don't Repeat Yourself). Here's a thread from MSDN forums on the topic:
DependencyProperty.AddOwner - What's the Point
Related
For years, I have felt I don't have a good understanding of WPF because I haven't found an authoritative reference on the possibilities. For example, I just found out that a ListBox has an attached ScrollViewer property.
<ListBox ScrollViewer.HorizontalScrollBarVisibility="Auto">
Other than reading a book or article that tells that, how would I know that ScrollViewer is a valid attached property? Is there a XAML schema document or something? How does Visual Studio Designer know?
ScrollViewer isn't an attached property; it's a class.
ScrollViewer.HorizontalScrollBarVisibility is an attached property. But it's not an attached property that ListBox "has"; it's an attached property that can be attached to any DependencyObject at all, including ListBox.
Here's what you see if you right click on ScrollViewer.SetHorizontalScrollBarVisibility and ScrollViewer.GetHorizontalScrollBarVisibility. A pair of static methods like this is required for an attached property. The first parameter is the thing you're attaching the property to. It doesn't have to be DependencyObject; it could be FrameworkElement, ListBox, ItemsControl, or anything else that can support dependency properties.
// Summary:
// Sets the value of the System.Windows.Controls.ScrollViewer.HorizontalScrollBarVisibility
// dependency property to a given element.
//
// Parameters:
// element:
// The element on which to set the property value.
//
// horizontalScrollBarVisibility:
// The property value to set.
public static void SetHorizontalScrollBarVisibility(DependencyObject element, ScrollBarVisibility horizontalScrollBarVisibility);
//
// Summary:
// Gets the value of the System.Windows.Controls.ScrollViewer.HorizontalScrollBarVisibility
// dependency property from a given element.
//
// Parameters:
// element:
// The element from which the property value is read.
//
// Returns:
// The value of the System.Windows.Controls.ScrollViewer.HorizontalScrollBarVisibility
// dependency property.
public static ScrollBarVisibility GetHorizontalScrollBarVisibility(DependencyObject element);
The ListBox itself quite likely has no clue what ScrollViewer.HorizontalScrollBarVisibility means, or even that it exists. But in the ListBox's template, there's probably a ScrollViewer, which will probably have a binding a lot like this:
<ScrollViewer
HorizontalScrollBarVisibility="{TemplateBinding ScrollViewer.HorizontalScrollBarVisibility}"
Put that attached property on any control that might have a ScrollViewer in its template, and if the template was written correctly, the ScrollViewer will use that value.
This is really, really nice because ListBox doesn't have to think about its own scrolling behavior. That's all delegated. Building controls by composition is extremely powerful.
The downside is that the whole thing is just a vast box of undifferentiated barf and it's real hard to make sense out of stuff. Intellisense can't tell you much about the scrolling behavior of ListBox when nobody outside that particular ListBox's template at the moment can even guess what that scrolling behavior might be.
So, in answer to your question: Yes. Basically you just have to read a lot of stuff. And keep a "Cool XAML Tricks" text file to note down cool stuff you hear about that you don't have a use for just yet.
But that's the way this profession has always been. Even with Intellisense, you can't use a class you don't know about.
Today I learned about ColumnDefinition.SharedSizeGroup and Grid.IsSharedSizeScope, and I learned that you can derive value converters from MarkupExtension and give them strongly typed, named properties instead of having to pass some goofy string into CommandParameter.
I believe the best docs we have right now are the MSDN documentation pages for WPF controls. For example, if you look up ListBox, you can find information about the attached ScrollViewer, and also it's full default template.
https://msdn.microsoft.com/en-us/library/cc278062(v=vs.95).aspx
I have a ComboBox that has its ItemsSource bound to a static List<CustomSettings> of options. The ComboBox is part of a form which is bound to a CustomObject class, and one of the properties on that class is a CustomSettingProperty.
I would like to bind the SelectedItem of the ComboBox to the property specified in the CustomObject, however SelectedItem="{Binding Path=CustomSettingProperty}" is not setting the default selected item. Using breakpoints I can see that it is calling the get; method, so I think the problem might be in the fact the CustomSettingProperty is created separately from the List<CustomObject> so WPF does not think it is the same item.
Is there an easy way to do this? Or perhaps an alternative since the CustomSettings class does contain an Id?
If the item that is selected is not the same instance that is contained in the List, you must override Equals() in the CustomObject to let the ComboBox know that it is the same object.
If it's the same instance, maybe it's only a simple thing such as setting the BindingMode to TwoWay:
SelectedItem="{Binding Path=CustomSettingProperty,Mode=TwoWay}"
I found the solution, It was The Prism's Event Aggregator was passed with reference type so That the ui thread stops processing
I have an ugly race condition with a WPF usercontrol, which is some kind of extended ComboBox:
The UserControl mainly defines two bindable DependencyProperties, one is the selected item, another one is a list, from which the selected item can be chosen.
Both are bindable, so the control may be initialized with or without a selected item and both properties can be changed via binding (on DataContext change), further the selection may change due to user interaction.
The UserControl contains a ComboBox, whose ItemsSource and SelectedItem are synchronized with my list-property and SelectedItem of the UserControl - so far so good.
The trouble now is, that if both properties are changed (quasi simultaneously) from outside when setting a new DataContext with both values set, it occasionally happens that the SelectedItem is set correctly but the list update causes the selection to be reset to null overwriting the previously set value -> corrupting my DataContext.
To make it short: I need to find a way to "lock" my SelectedItem during list update - but just observing the PropertyChanged-Events is not enough, since I receive them AFTER the updates, where the state to remember is already lost. Further I cannot identify, if the selection change was caused by the user or by (correctly) the binding or (not desired) indirectly by the other binding...
I think I would need some BeforePropertyChanged or OnPropertyChanging event for my DependencyProperties - or another way to manage the ordering of simultanous updates of both properties.
Any suggestions welcome :)
Note that I talk of a list to select an item from, but actually it is some more complex structure that allows quick sorting and filtering, that is also the reason why I do not use an ItemsControl here, but I don't feel like that's relevant for the question.
This may not help the situation, and is probably not the right way to do this, however you spoke of an OnPropertyChanging event for your dependency properties.
It just so happens that when you create dependency properties you can specify a callback in the PropertyMetadata that fires when the property changes, which has both the old and the new values in its EventArgument.
Here is an example of a Text property with a callback
public static DependencyProperty TextProperty = DependencyProperty.Register
("Text", typeof(string),
typeof(DecimalTextBox),
new PropertyMetadata("", OnTextPropertyChanged));
The last parameter is the one you are looking for. The first parameter of the PropertyMetadata constructor is a default value for the property. The second one is where you register a propertychanged callback that happens when the property changes.
in this callback you can handle the bindings to make sure that you don't overwrite your datacontext's SelectedItem.
private static void OnTextPropertyChanged(DependencyObject sender, DependencyPropertyChangedEventArgs e)
{
var box = ((TextBox)sender);
if (((string)e.NewValue)==badvalue)
box.Text= e.OldValue);
}
To be honest I'm not sure how this helps you with your situation, as I would still not know how to check whether the null value is valid or not. (what I might do is not allow null values if there is an ItemsSource unless the itemssource is just changing [and I might use some kind of flag in the ItemsSource changed callback that gets reset once the selecteditem is changed]). I'm not very clued up on async, but you could perhaps put some sort of lock in here.
u_u
I'm having one hell of a time trying to get my databinding to work correctly. I have reason to believe that what I'm trying to accomplish can't be done, but we'll see what answers I get.
I've got a UserControl. This UserControl contains nothing more than a button. Now within the code behind, I've got a property name IsBookmarked. When IsBookmarked is set, code is run that animates the look of the button. The idea is that you click the button and it visually changes. We'll call this UserControl a Bookmark control.
Now I have another control, which we'll call the FormControl. My FormControl contains a child Bookmark control. I've tried to do databinding on my Bookmark control, but it's not working. Here's some code to help you out.
This is the XAML and Loaded event handler of my control. As you can see it contains a child element that is a custom control (bookmark). So once this control loads, it's DataContext is set to an new instance of an Employee object. Silverlight also sets the DataContext property of my child bookmark control to the same instance. I've verified this by debugging. If my parent has a valid DataContext set then why can't my child control (bookmark) property databind to it?
<UserControl ......>
<q:Bookmark x:Name="BookMarkControl1" IsBookmarked="{Binding IsSiteBookmarked}" />
</UserControl>
public void Control_Loaded(object sender, EventArgs e)
{
DataContext = new Employee { IsSiteBookmarked = True };
}
This is my custom control below. Obviously it contains more than this, but for readability I've trimmed it down to the property I'm trying to databind to.
//this is the bookmark control. I've included this control within another control, and I'm trying to databind to properties within my parents DataContext
public partial class Bookmark : UserControl
{
bool _IsBookmarked= false;
public bool IsBookmarked
{
get {return _IsBookmarked;}
set {
_IsBookmarked= value;
SwitchMode(value);
}
}
}
UPDATE
Got some javascript errors that I should mention. Firebug reports a AG_E_PARSER_BAD_PROPERTY_VALUE exception. It doesn't seem like my databinding is even working yet.
Make your IsBookmarked property on the Bookmark control a dependency property.
I presume Control_Loaded is a part of your FormControl, in which case I'm not sure you are using DataContext properly. Best double check that.
UPDATE: Yes, you are using the DataContext properly. AG_E_PARSER_BAD_PROPERTY_VALUE indicates you need to make the IsBookmarked property a dependency property, like so:
Public Property IsBookmarked() As Boolean
Get
Return Me.GetValue(IsBookmarkedProperty)
End Get
Set(ByVal value As Boolean)
Me.SetValue(IsBookmarkedProperty, value)
End Set
End Property
Public Shared ReadOnly IsBookmarkedProperty As DependencyProperty = DependencyProperty.Register("IsBookmarked", GetType(Boolean), GetType(Bookmark), New PropertyMetadata(New PropertyChangedCallback(AddressOf OnIsBookmarkedPropertyChanged)))
Private Shared Sub OnIsBookmarkedPropertyChanged(ByVal d As DependencyObject, ByVal e As DependencyPropertyChangedEventArgs)
Dim cntrl As Bookmark = TryCast(d, Bookmark)
cntrl.SetIsBookmarked(e.NewValue)
End Sub
If you only need to store the value for later use, then you don't need to do anything in the OnIsBookmarkedPropertyChanged procedure, But I put some code there as an example anyway.
Good Luck!
I don't recall the exact order in which databinding is evaluated (and I'm too lazy to go look it up), but as I recall, it initially happens BEFORE the form's Loaded event fires, and without making the IsBookmarked property a dependency property, or at least using INotifyPropertyChanged, it may have trouble establishing the datacontext appropriately. I'd recommend either implementing INotifyPropertyChanged or making IsBookmarked a dependency property. DataBinding is tough enough to get right in the best of circumstances (see my long, bad-tempered rant about it here), and you'll just be making it more difficult on yourself if you aren't setting up your properties in the way that it expects.
The control exposes a IsSiteBookmarked property(which I believe should be a DependencyProperty) but the control is binding to a IsBookmarked which is not shown. Is this intentional? Have you checked your Visual Studio output window for binding errors?
Addition 1:
Since you have fixed the typo in your question and added that there is an error being reported.
Start by clearing up the AG_E_PARSER_BAD_PROPERTY_VALUE problem. Is there a line number and start position in the error message? Start looking there. One strategy is to start taking out XAML until there is no longer an error. This will narrow down the offending code.
Running in debug, mode check for binding errors in the output window.
You might want to also post the Employee class code, especially the IsSiteBookmarked property.
Typically when doing databinding to an object you will want to leverage the INotifyPropertyChanged interface and implement that so that the control can properly invalidate it's property value. Unless you use INotifyPropertyChanged with Mode=TwoWay then any code that changes your DataContext's IsSiteBookmarked will have no effect.
Databinding in WPF/Silverlight revolves around dependency properties, DataContext objects and DataSource objects. As far as I can tell, dependency properties are the same thing as ambient properties and their significance to binding is basically that if you put a bunch of widgets in a container then you only need to specify a DataContext for the container.
There are several parts to this question.
What is the difference between DataContext and DataSource, and how do they relate?
What manages cursors in WPF/Silverlight databinding? Is there a direct equivalence to the WinForms CurrencyManager and BindingContext?
How do I go about manipulating a Cursor in WPF/Silverlight databinding?
DataGrid seems to have a CurrentItem property. If you bind a bunch of widgets to the various columns of a datasource and they share the same datacontext as the datagrid then interactively moving the selected row in the datagrid changes the row whose values are expressed in the widgets. Could someone please explain to me how it all fits together? Preferably with reference to SL4.
When I do this:
private void buttonNew_Click(object sender, RoutedEventArgs e)
{
Guid newId = Guid.NewGuid();
Employee emp = new Employee() { Id = newId, FirstName = "NOT SET", LastName = "NOT SET" };
AtomDomainContext adc = employeeDomainDataSource.DomainContext as AtomDomainContext;
DomainDataSourceView ddsv = grid1.DataContext as DomainDataSourceView;
}
I get this compilation error:
The type 'System.ComponentModel.IPagedCollectionView' is defined in an assembly
that is not referenced. You must add a reference to assembly 'System.Windows.Data,
Version=2.0.5.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35'.
D:\Argent\Views\ManageEmployees.xaml.cs, 57, 7, Argent
which sounds easy to fix but when I attempt to add a reference to the Argent project the list of references is empty; presumably one is confined to those assemblies that Silverlight deploys to the target computer. So now what do I do?
I found some answers so in the absence of a useful contribution from anyone else I'll answer my own question.
A DataContext is a kind of cursor object. You assign to the DataContext property any object or IEnumerable collection of objects to which you want to bind, and a wrapper is constructed around it. If you assign an IEnumerable, the DataContext surfaces a CurrentItem property that references one of the elements of the IEnumerable. If you assign something that isn't an IEnumerable, the DataContext wrapper behaves as though it contructs an IEnumerable and adds your object to the collection and then proceeeds as if that was what you passed in the first place, the object being set up as the CurrentItem.
One possible IEnumerable is the DomainDataSource, for which DataSource is a base clase.
Every widget in Silverlight has a DataContext property. Generally you don't set this directly, due to what Microsoft has taken to calling "dependency properties" which as far as I can tell are exactly the same as ambient properties, which is to say that unless you set them explicitly they "inherit" a value from the immediate container, which may in turn so inherit. So instead of setting the same IEnumerable as DataContext on a bunch of widgets, you make them all children of some container and set the DataContext for that, and they all miraculously get bound to the same cursor.
You can create a new DataContext object in XAML simply by explicitly specifying it; this creates a new instance and assigning it to the DataContext property of the widget on which you specify it; this is a new instance, a new cursor that is independent of any other DataContext.
In Silverlight4 you can reference the DataContext in use by another object; see element binding.
But a binding is only partly specified by a DataContext. Having specified a DataContext so that a widget has object foo contributing its context, specifying a binding path of A will look for a property named A on object foo and if this is found will mashall its value to and from your widget.
What's really confusing to the newbie is that while the whole binding can be specified in one spot, normally the context is specified miles away up a big complex container hierarchy, and just the path is specified on each widget, yet for (eg) binding the ItemsSource of a combobox to a lookup table you do specify the whole thing. I hope I've made it all a bit clearer for those following in my footsteps.
As for the location of the elusive 'System.Windows.Data', it's in %ProgramFiles%\Microsoft SDKs\Silverlight\v4.0\Libraries\Client\System.Windows.Data.dll