DependancyProperty Confusion with Custom Controls and ModelView
-
- First issue I see is that your dependency properties are set up incorrectly. Think about whats happening here... SelectedItemsProperty and DeSelectedItemsProperty are static (meaning a single instance in this case). You have set the values to new ObservableCollection(). What you end up with is *EVERY* DualListControl in the world is using the same ObservableCollection(). You also allow users to overwrite the collections completely. Not something you want to do. Use DependencyProperty.RegisterReadOnly() to register the property as a read-only DP and create the ObservableCollection() in the public DualListControl() constructor. Something like: public DualListControl() { SetValue(SelectedItemsPropertyKey, new ObservableCollection()); } then remove the setters for those properties. 2) Bindings in generic.xaml should be TemplateBinding, not binding.
SledgeHammer, Thanks for your time and comments Re point one, DependancyProperties obviously still confuse the life out of me! I tried making this a readonly collection and then realised what you are suggesting, you have given me the method required if I want a single list for all DualListControls right? but these can no longer be ovverriden by a user. That is not my intention, what I am trying to achieve and failing is to be allow a developer to do something like this
<Grid> <CustomControls:DualListControl Name="List" SelectedItems="{Binding SelectedItemsA}" DeSelectedItems="{Binding DeslectedItemsA}"/> </Grid>The problem I appear to have is that the SelectedItems dependancy property is not being bound to the one in the MainAppViewModel. Re point two, Ian has already found this and corrected me, the bindings in the Generic.xaml are now as the follows
<ListView Grid.Column="2" Name="ElementSelectedList" ItemsSource="{TemplateBinding SelectedItems}"/>
Have I understood this correctly?
Just racking up the postings
-
Unfortunatly this is already done. I have double checked and I can see while debugging that both the MainAppView and the DualListControl instance have the DataContext set to the same instance of the MainAppViewModel class. The Content of the main window is set as follows
public MainWindow() { InitializeComponent(); Content = new MainAppViewModel(); }And in the App.xaml i have a DataTemplate telling WPF how to render the object as follows
<Application x:Class="TestApplication.App"
xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
xmlns:ViewModels="clr-namespace:TestApplication.ViewModels"
xmlns:Views="clr-namespace:TestApplication.Views"
StartupUri="MainWindow.xaml">
<Application.Resources>
<DataTemplate DataType="{x:Type ViewModels:MainAppViewModel}">
Views:MainAppView/
</DataTemplate>
</Application.Resources>
</Application>If you see what I mean So the part that is missing is the actual binding of the DualListControls dependancy properties being bound to the MainAppViewModels SelectedListA and DeSelectedListA properties. Any ideas as to what I have missed?
Just racking up the postings
Pardon the slow response... Busy busy... Anyway... I'm running out of ideas here... Have you checked for any reported data binding errors? They don't pop up as exceptions, but if you bring up the Output window in your IDE, they should show up there.
Proud to have finally moved to the A-Ark. Which one are you in?
Author of the Guardians Saga (Sci-Fi/Fantasy novels) -
SledgeHammer, Thanks for your time and comments Re point one, DependancyProperties obviously still confuse the life out of me! I tried making this a readonly collection and then realised what you are suggesting, you have given me the method required if I want a single list for all DualListControls right? but these can no longer be ovverriden by a user. That is not my intention, what I am trying to achieve and failing is to be allow a developer to do something like this
<Grid> <CustomControls:DualListControl Name="List" SelectedItems="{Binding SelectedItemsA}" DeSelectedItems="{Binding DeslectedItemsA}"/> </Grid>The problem I appear to have is that the SelectedItems dependancy property is not being bound to the one in the MainAppViewModel. Re point two, Ian has already found this and corrected me, the bindings in the Generic.xaml are now as the follows
<ListView Grid.Column="2" Name="ElementSelectedList" ItemsSource="{TemplateBinding SelectedItems}"/>
Have I understood this correctly?
Just racking up the postings
No, what you have *NOW* will result in every DualListControl sharing the same ObservableCollection instance. I'll assume that you want each one to have its own. The solution I gave you will give each instance its own collection. The UserControl doesn't have its DataContext set, so those Binding will not work. The bindings in Generic.xaml should be TemplateBinding.
-
Unfortunatly this is already done. I have double checked and I can see while debugging that both the MainAppView and the DualListControl instance have the DataContext set to the same instance of the MainAppViewModel class. The Content of the main window is set as follows
public MainWindow() { InitializeComponent(); Content = new MainAppViewModel(); }And in the App.xaml i have a DataTemplate telling WPF how to render the object as follows
<Application x:Class="TestApplication.App"
xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
xmlns:ViewModels="clr-namespace:TestApplication.ViewModels"
xmlns:Views="clr-namespace:TestApplication.Views"
StartupUri="MainWindow.xaml">
<Application.Resources>
<DataTemplate DataType="{x:Type ViewModels:MainAppViewModel}">
Views:MainAppView/
</DataTemplate>
</Application.Resources>
</Application>If you see what I mean So the part that is missing is the actual binding of the DualListControls dependancy properties being bound to the MainAppViewModels SelectedListA and DeSelectedListA properties. Any ideas as to what I have missed?
Just racking up the postings
You need to set the DataContext on your View to point to your model.
-
You need to set the DataContext on your View to point to your model.
No, he has that part right, I believe... He's using a DataTemplate, so it goes like this: 1) MainWindow has its Content set to the model 2) Content is rendered using a DataTemplate which contains a MainAppView (If this failed, he wouldn't see his control at all) 3) MainAppView, being inside a DataTemplate, uses that model as its DataContext 4) MainAppView contains a DualListControl, with its SelectedItems and DeselectedItems properties bound to that model 5) DualListControl is rendered using a DataTemplate, which contains two ListViews that are template-bound to those properties It's a bit more indirect than I would have done, but it should work. #1 and #2 are solid... #3 is what you're talking about, but that should happen automatically. #5 is the TemplateBinding thing he already fixed... I think the broken link is in #4, just by process of elimination, but I don't see the actual problem.
Proud to have finally moved to the A-Ark. Which one are you in?
Author of the Guardians Saga (Sci-Fi/Fantasy novels) -
No, he has that part right, I believe... He's using a DataTemplate, so it goes like this: 1) MainWindow has its Content set to the model 2) Content is rendered using a DataTemplate which contains a MainAppView (If this failed, he wouldn't see his control at all) 3) MainAppView, being inside a DataTemplate, uses that model as its DataContext 4) MainAppView contains a DualListControl, with its SelectedItems and DeselectedItems properties bound to that model 5) DualListControl is rendered using a DataTemplate, which contains two ListViews that are template-bound to those properties It's a bit more indirect than I would have done, but it should work. #1 and #2 are solid... #3 is what you're talking about, but that should happen automatically. #5 is the TemplateBinding thing he already fixed... I think the broken link is in #4, just by process of elimination, but I don't see the actual problem.
Proud to have finally moved to the A-Ark. Which one are you in?
Author of the Guardians Saga (Sci-Fi/Fantasy novels)Well, its a retarded way to do it and he should unretard it. Not make it more retarded :). If he did it the correct way, he wouldn't be trouble shooting wacky issues. Oh wellz :).
-
No, what you have *NOW* will result in every DualListControl sharing the same ObservableCollection instance. I'll assume that you want each one to have its own. The solution I gave you will give each instance its own collection. The UserControl doesn't have its DataContext set, so those Binding will not work. The bindings in Generic.xaml should be TemplateBinding.
SledgeHammer, I appreciate your time. I understand your point about a single list instance being shared amongst all controls. Please understand that I have been making changes as recommended by yourself and Ian (above). The complication that arises with the ReadOnly method you describe is that I would like to be able to allow the consumer to use the control in the following way. The ReadOnly method does not allow me to do this. Any suggestions?
<CustomControls:DualListControl SelectedItems="{Binding SelectedItemsA}" DeSelectedItems="{Binding DeSelectedItemsA}" Width="300" Height="300"/>Regarding the DataContext, the control template does not appear to require the DataContext specifically set as the ViewModel is implicitly bound to the parent view and therefore to this control, I have verified this while debugging. I do have the control working as intended but only tested as a single instance at the moment, I will test with mutiple instances to enable me to fix the single list instance issue you have kindly pointed out. Once again, thanks for your time.
Just racking up the postings
-
No, he has that part right, I believe... He's using a DataTemplate, so it goes like this: 1) MainWindow has its Content set to the model 2) Content is rendered using a DataTemplate which contains a MainAppView (If this failed, he wouldn't see his control at all) 3) MainAppView, being inside a DataTemplate, uses that model as its DataContext 4) MainAppView contains a DualListControl, with its SelectedItems and DeselectedItems properties bound to that model 5) DualListControl is rendered using a DataTemplate, which contains two ListViews that are template-bound to those properties It's a bit more indirect than I would have done, but it should work. #1 and #2 are solid... #3 is what you're talking about, but that should happen automatically. #5 is the TemplateBinding thing he already fixed... I think the broken link is in #4, just by process of elimination, but I don't see the actual problem.
Proud to have finally moved to the A-Ark. Which one are you in?
Author of the Guardians Saga (Sci-Fi/Fantasy novels)Ian, You are correct in the way DataContext is set. I am using a method learned from one of the MVVM mechanism described on a tutorial published in CodeProject, I forget the Authors name right now, search WPF MVVM. As mentioned in another comment, I do somehow have this working and will publish my fixes here when I have got close to understanding how I fixed it. Something to do wth the MetaData part and creating an instance of the list in the constructor. Like I said, I will put my changes up as soon as I can. I also appreciate that I may have a single list instance issue as mentioned by SledgeHammer. Again, thanks for your time, there is nothing worse than head butting a brick wall.
Just racking up the postings
-
Well, its a retarded way to do it and he should unretard it. Not make it more retarded :). If he did it the correct way, he wouldn't be trouble shooting wacky issues. Oh wellz :).
Concerning the Retaded way this is done, can you elaborate? I am not sure I understand what you think is wrong with my MVVM implementation. I am not shooting or getting upset, please do not misread my comment in that way, I am only trying to learn. All of the source code is available above. How would you achieve MVVM?
Just racking up the postings
-
SledgeHammer, I appreciate your time. I understand your point about a single list instance being shared amongst all controls. Please understand that I have been making changes as recommended by yourself and Ian (above). The complication that arises with the ReadOnly method you describe is that I would like to be able to allow the consumer to use the control in the following way. The ReadOnly method does not allow me to do this. Any suggestions?
<CustomControls:DualListControl SelectedItems="{Binding SelectedItemsA}" DeSelectedItems="{Binding DeSelectedItemsA}" Width="300" Height="300"/>Regarding the DataContext, the control template does not appear to require the DataContext specifically set as the ViewModel is implicitly bound to the parent view and therefore to this control, I have verified this while debugging. I do have the control working as intended but only tested as a single instance at the moment, I will test with mutiple instances to enable me to fix the single list instance issue you have kindly pointed out. Once again, thanks for your time.
Just racking up the postings
Ok... So, what you are initially doing is having every instance of your control share the same instance of ObservableCollection. However, you do allow the user to overwrite said instance through your property setter. That will cause you *many* problems down the road with data binding. One area where WPF crumbles hard is when you start switching around instances of objects or creating temporary objects, etc. because it depends on those being the same object to function. Now, C# doesn't have pointers, but I will use them to illustrate what I am trying to explain. 1) you create your control, your control creates an ObservableCollection() [0x1000] 2) a user of your control subscribes to [0x1000].CollectionChanges 3) a user calls your setter with a new ObservableCollection() [0x2000] Guess what happened? Everybody subscribing to the [0x1000] collection events is now broken. Everybody making changes to the [0x1000] collection is broken as well. [0x1000] is now orphaned. What you want is for each instance of your control to create its own ObservableCollection and *NEVER* let anybody change that. It is important that if you created [0x1000], that it remains [0x1000] for the lifetime of your control. Otherwise bad things will happen. Now, the read-only DP will not fulfil your just mentioned requirement of binding to collections. Fair enough. What you are trying to do here is combining TWO techniques into ONE which will cause you the problems just mentioned. If you look at the ListView or TreeView for example, you will see the proper way to lay out your control. public ObservableCollection Items // this *MUST* be read-only { get { ... } } public IEnumerable ItemsSource /// this is how people will pass in collections { get { ... } set { ... } } So what happens here is that people can add items manually to the Items collection OR use the ItemsSource to pass in collections. If you only need to allow passing in collections, use the IEnumerable ItemsSource method instead. If you want to support both, you need to add some "protection" code... i.e. don't allow use of Items if ItemsSource is not null and vice versa, etc.