Generic framework or pattern for adding colomns to a WPF ListView
-
I'm not really sure what Bob's response has to do with your question. Nothing at all from what I can tell :). This is really a WPF question and not a C# question, but I read both boards and just dealt with this issue myself recently, so I'll help you out :). 1) The WPF ListView doesn't support data binding on the GridViewColumnCollection out of the box. You can add support for this, not too difficult, but a little bit of work. 2) Once you have a WPF ListView that can support data binding on the GridViewColumnCollection, its just a matter of having your VM return a collection of columns. 3) Some gotcha's you'll run into: a) a GridViewColumn can only be owned by one GridViewColumnCollection at a time, so you can't return a GridViewColumnCollection from your VM, you need to return an ObservableCollection. b) defining a GridViewColumn in code with bindings is a major PITA, so you should devise a way to load them out of a XAML file where you'll again run into "issue a" where you can't share GridViewColumn's. All these issues are overcomeable... basically what I ended up with was a GridViewEx class that supported two-way binding on the column collection. Remember, you are going to need to save column widths and column order :).
What it has to do with the question is that you can bind a ObservableCollection<BindingWithCustomColumns<T>> as the ItemsCollection of a ListView and it should act like an ObservableCollection<T> except that you can also add extra columns. Though thinking about it some more you probably want to make the dictionary static if you want the same extra columns for every instance of T ... not sure what the data binding does if the list of things it's binding to claims to have different properties. (Note that my solution is done by analogy with something similar I did to bind a WinForms DataGridView with dynamic column binding. I wasn't aware that you could explicitly bind the columns as your post seems to indicate.)
-
What it has to do with the question is that you can bind a ObservableCollection<BindingWithCustomColumns<T>> as the ItemsCollection of a ListView and it should act like an ObservableCollection<T> except that you can also add extra columns. Though thinking about it some more you probably want to make the dictionary static if you want the same extra columns for every instance of T ... not sure what the data binding does if the list of things it's binding to claims to have different properties. (Note that my solution is done by analogy with something similar I did to bind a WinForms DataGridView with dynamic column binding. I wasn't aware that you could explicitly bind the columns as your post seems to indicate.)
Ah, your solution is for a WinForms DataGridView :). A WPF ListView is a *completely* different animal. ListView.ItemsSource would point to an ObservableCollection, but columns are defined in a *completely* different place. Also, when you define the columns, you need to define what member of SomeClass will be shown for each column. The WPF ListView column collection doesn't support binding out of the box as I indicated in my other post. You have to do some work to get that to work. In WPF you generally need to tell the control what property to display. Another note is that WPF XAML does NOT play nice with generics. You should generally avoid using them for objects that are going to be displayed. Well, I don't mean don't use them, but I mean, you need to do something like: public SomeClassCollection : ObservableCollection { } and then use SomeClassCollection everywhere since you can't specify ObservableCollection in XAML.
-
Ah, your solution is for a WinForms DataGridView :). A WPF ListView is a *completely* different animal. ListView.ItemsSource would point to an ObservableCollection, but columns are defined in a *completely* different place. Also, when you define the columns, you need to define what member of SomeClass will be shown for each column. The WPF ListView column collection doesn't support binding out of the box as I indicated in my other post. You have to do some work to get that to work. In WPF you generally need to tell the control what property to display. Another note is that WPF XAML does NOT play nice with generics. You should generally avoid using them for objects that are going to be displayed. Well, I don't mean don't use them, but I mean, you need to do something like: public SomeClassCollection : ObservableCollection { } and then use SomeClassCollection everywhere since you can't specify ObservableCollection in XAML.
-
Oh right you have that whole ItemTemplate business. I remember now. So yeah treat my post as an interesting diversion and do what this guy says :p
Trust me... once you pick up MVVM & WPF, you'll wonder why you ever wasted your youth on MFC and WinForms :).
-
I'm not really sure what Bob's response has to do with your question. Nothing at all from what I can tell :). This is really a WPF question and not a C# question, but I read both boards and just dealt with this issue myself recently, so I'll help you out :). 1) The WPF ListView doesn't support data binding on the GridViewColumnCollection out of the box. You can add support for this, not too difficult, but a little bit of work. 2) Once you have a WPF ListView that can support data binding on the GridViewColumnCollection, its just a matter of having your VM return a collection of columns. 3) Some gotcha's you'll run into: a) a GridViewColumn can only be owned by one GridViewColumnCollection at a time, so you can't return a GridViewColumnCollection from your VM, you need to return an ObservableCollection. b) defining a GridViewColumn in code with bindings is a major PITA, so you should devise a way to load them out of a XAML file where you'll again run into "issue a" where you can't share GridViewColumn's. All these issues are overcomeable... basically what I ended up with was a GridViewEx class that supported two-way binding on the column collection. Remember, you are going to need to save column widths and column order :).
I had the feeling that BobJanova's answer was not very related, hence the 'investigating....' I didn't even notice we have a special WPF section. Guess I have been posting in the wrong section. Thanks again for all the input!
-
Trust me... once you pick up MVVM & WPF, you'll wonder why you ever wasted your youth on MFC and WinForms :).
I dodged MFC (thankfully) but I actually quite like the WinForms approach. I don't really see the point in WPF – it's a great way of producing slightly confusing applications that violate the normal conventions of desktop apps, and its layout engine is brilliant at producing something which is nearly but not quite what you want. Silverlight makes more sense, as that approach to UI is more in line with the way the web works. I do like the MVVM pattern, it seems to be one of the cleanest 'MV*' approaches for separation of concerns – but there's no reason one shouldn't write WinForms or even web code in a similar style (and in fact ASP 4.0 seems to have gone down that road with its MVC).
-
I dodged MFC (thankfully) but I actually quite like the WinForms approach. I don't really see the point in WPF – it's a great way of producing slightly confusing applications that violate the normal conventions of desktop apps, and its layout engine is brilliant at producing something which is nearly but not quite what you want. Silverlight makes more sense, as that approach to UI is more in line with the way the web works. I do like the MVVM pattern, it seems to be one of the cleanest 'MV*' approaches for separation of concerns – but there's no reason one shouldn't write WinForms or even web code in a similar style (and in fact ASP 4.0 seems to have gone down that road with its MVC).
Huh? How can you like Silverlight, but not like WPF? They are the same thing! Silverlight is a stripped down version of WPF. Winforms is pretty much MFC with primitive data binding support. Not quite sure what you find confusing about WPF. The layout engine always gives me exactly what I want as its a million times more powerful and flexible then the Winforms one. Oh well... too each his own I guess.
-
Huh? How can you like Silverlight, but not like WPF? They are the same thing! Silverlight is a stripped down version of WPF. Winforms is pretty much MFC with primitive data binding support. Not quite sure what you find confusing about WPF. The layout engine always gives me exactly what I want as its a million times more powerful and flexible then the Winforms one. Oh well... too each his own I guess.
I like Silverlight and not WPF because the types of UI you produce fit quite nicely into the Web 2.0 paradigm, but generally not into what is expected from a desktop app. It's quite difficult in WPF to produce something that looks like a standard Windows app (right?). I'm sure there's some unfamiliarity as well but it just seems more suited to the web to me.
-
I like Silverlight and not WPF because the types of UI you produce fit quite nicely into the Web 2.0 paradigm, but generally not into what is expected from a desktop app. It's quite difficult in WPF to produce something that looks like a standard Windows app (right?). I'm sure there's some unfamiliarity as well but it just seems more suited to the web to me.
? Out of the box, WPF will produce apps that look exactly like Winforms apps. Its just, remember all that crazy code you wrote to do Owner Draw & Custom Draw controls? SetPixel, GetPixel, BitBlt, etc? In WPF that 1000 lines of code is now 2 lines of XAML pretty much. WPF is pretty much Winforms + superior data binding + superior custom drawing support.
-
? Out of the box, WPF will produce apps that look exactly like Winforms apps. Its just, remember all that crazy code you wrote to do Owner Draw & Custom Draw controls? SetPixel, GetPixel, BitBlt, etc? In WPF that 1000 lines of code is now 2 lines of XAML pretty much. WPF is pretty much Winforms + superior data binding + superior custom drawing support.
Modifying controls in WPF requires you to replace the XAML template, doesn't it? Maybe it's just that all the material on WPF focuses on the 'cool stuff' and not making normal apps. Even Microsoft's introductory topic[^] is 'shiny' and web-like in the interfaces it shows, though.