I'm starting to develop a WP7 app with MVVM Light. I want to make use of the pivot control to show two different lists of different item types. Would it be best practice to create the PivotItems as UserControls or should I stick everything in one viewmodel?
I think there is no "correct" way to do it, it just depends on your vision.
Personnally, I always create separate UserControls to act as PivotItems.
The main objective is to make my code clearer, with more separate classes it is way more easily unserstandable!
However it also depends on the complexity of the items. Don't feel forced to create one UserControl per item, just separate if the control is quite complex and requires quite a lot of XAML lines, it will clarify your code
Related
I implemented a file input mask as a user control that I want to re-use in my WPF application in two different contexts.
While the view (in the two cases) is actually pretty much the same, the ViewModel and the logic I implemented there is quite different.
I have already tried to inherit from a common AbstractFileInputView together with an abstract ViewModel, but that seems to break as soon as I put it in XAML.
Since I wasn't able to find some actual documentation about how to build re-usable (abstract) user controls, I am wondering if somebody has any hints on how to solve this?
Or do I really just have to go on a copy-and-paste spree here?
I am new to WPF having previously worked with WinForms on occasion and I still trying to get my head around the WPF mentality, which given my background is embedded coding, seems quite removed.
In my project I need to create a Grid Panel "template", which I'll call "Fred" (where in this case Fred is simply a cluster of graphically customized buttons) and spawn multiple instances of this to the UI programmatically based on external events. I am finding it hard to see an obvious way to do this (perhaps that is because there maybe multiple ways?) and have looked into ControlTemplates, Styles and Custom Elements. I suspect the solution lies in the latter but I am also concerned I might be thinking about this in the wrong way. To me it seems to make sense to visualize Fred as a Grid resource that I can programmatically invoke somehow when I need to create a new instance, but given I found it hard to "google" this very thing then perhaps I am going about this all wrong?
I apologies if this is a bit vague.
My question here is two fold:
Is this a sensible way to achieve my end goal i.e. if I need to programmatically spawn this cluster of customized Buttons (Fred) then does it make sense to contain these in a Grid that can be accessed by the main C# or is there a more standard way that I am missing to achieve this?
Depending on the answer to (1) are there code examples to achieve this?
The concept you are looking for is an "ItemsControl" (which is itself a usable class, and also has several derived classes like ListView and ListBox) in combination with DataTemplates.
In this case you would make "Fred" a DataTemplate (commonly as the direct descendant of your ItemControls ItemTemplate property in XAML). You then bind ItemsSource to a collection (should be ObservableCollection<T> for runtime additions/deletions).
All of this relies on using the MVVM pattern (which coming from WinForms you probably aren't). I would suggest looking at MSDN, Stack Overflow, an excellent blog series by Reed Copsey: http://reedcopsey.com/series/windows-forms-to-mvvm/ or just google "WPF and MVVM" to learn more.
To answer your questions explicitly:
Yes; you have the right concept but are thinking about it in WinForms terms/practices. Use MVVM instead.
Yes; there are many resources available.
So I've just started developing C# WinForm applications and each project I've been working on seems to be larger and requires more user functionality. If I add all of the functionality to one form, obviously it can get out of control very quickly. My last project I would divide up the functionality into individual Forms, and whenever someone say wanted to perform "Feature1" I would instantiate Feature1 Form and show it as a dialog with the main Form as it's owner (so they couldn't click off it).
I'm just curious of what other methods are out there for keeping code organized within Forms. If you are forced to have tons of features/functionality on a single form is there a good way to keep items organized? I simply hate having a code file with hundreds/thousands of lines long.
The answer may simply be in the design, try to design the UI up front so you can utilize multiple forms?
Another example I faced. I created a Tab Control and had about 5 tabs. Those 5 tabs had tons of features and were all stored in the same CS file. What other options did I have? Create a new custom TabControl class with my specific functionality for that tab in it?
I don't mind reading, so if there are decent articles out there feel free to link them!
The go-to method is a Controller/Presenter. The idea is that the window should only be responsible for actually handling the UI events of its controls, and it should do so by calling methods on a Controller which do the real work for the window. The window can either have the handlers necessary or it may link the UI events directly to Controller methods; the former is usually the easier method, but it can be tempting to sneak in a line of code here or there that really should be in the Controller method. By doing this, you sever the layout and presentation logic in the Form class with the business logic in the Controller.
Mark Hall's suggestion of User Controls is also a good one. By creating UserControl classes for tabs or for common UI control combinations, you sever the logic responsible for laying out that part of the UI from the main form's code, and the control then just "drops in" and the window works with it in a much simpler way. This is a must for implementing custom but reusable controls; the fundamental tenet of DRY is that if you have two lines of code in two different places doing the same job to two different but interchangeable things, those lines of code should be merged into one place.
I have used UserControls in my projects to group functionality into separate objects that can then be added to your Form.
I tend to split my logic code from the UI as recommended. If you do this, you need to be somewhat cautious with how calls are made across the application to avoid Cross Thread Exceptions. I was taught to create delegates and events to update the UI from the logic class, but MSDN of course also has a lot of information on making thread safe calls.
I know this is a late answer, but if anyone still reads this question, another way to reduce the number of lines of code in your form is to use Data Bindings. If you are using properties, Data Bindings make it so that you don't have to constantly write handlers just to do something like PropertyName = textBox.Text;. Data Bindings work with both datasets and objects.
Recently i got explained that MVVM can only be done "the right way" if i use DataTemplates. Is this truely the case?
I'd say its a good idea to use DataTemplates if you want highly reusable "Views".
But if i am going to develop an application that has, say, five to ten different pages, and there is very little to none reuse of specific controls (like the "Person" view is only used once, and its highly likely that this requirement doenst change), why cant i simply create a usercontrol and put that directly into the code?
Am i missing some important core principle of MVVM here?
Main selling point of MVVM is separation of View from the ViewModel (so that VM doesnt know about View) by using powerful Binding feature of WPF.
DataTemplates are a just another feature which allows you to represent data in different way. As you have said, if you dont have reusable DataTemplate then dont create one, even if you do make sure it resides in the View's Resources, you can share it wider group if you wanted do.
using UserControl can be useful where you need to do something extra (apart from simple representing data), for example, some complex validation or extra commands/buttons
I dont think MVVM and DataTemplates are related in the same context.
There is no special needing for DataTemplate, you have a view and a viewmodel that cooperates with databindings and events. The MVVM goal in WPF is to remove the code from the view to achieve a real presentation only view, and not a messy code behind store. Having the ViewModel agnostic from the view is another goal, even if not always achieved.
I want to create two diffent types of DockPanels. If the user clicks on one link, it loads DockPanel #1 otherwise it loads #2.
Can we dynamically swap them? I'm new to WPF. In REALBasic, I'd use GroupPanels and I'd swap them if needed.
Thanks
U can dynamicly create controls and fill their content with other controls. Or u can just place both types and hide one u dont want to show.
Take a look at Josh Smith's MVVM Article in MSDN Magazine. Josh is considered by many to be The MVVM Guru, and this article does a good job at explaining the basics.
With that in mind, I would probably do your app as an MVVM application.
The Model would "just" be your data model (much like in MVC).
Next there would be a View for each of your panels. Each View could either be set up as a DataTemplate (like in the article), or as a UserControl (as I've done and seen done many other places as well). Doing so makes it modular, and easier to expand, maintain, etc.
Your MainWindow is really also considered a View, onto which you place other Views.
All of the Views will be controlled by one or more ViewModel classes. How many you have depends on your design. Generally, if there is distinct functionality, you will have a more-or-less one-to-one relationship between a View and a ViewModel (although you can certainly share multiple Views with a single ViewModel). There will also generally be a single "Main ViewModel" class to hold everything together.
In general terms given the general description of your problem, it is likely that your ViewModel will contain a Command (or Commands), handled when your user chooses a link. This Command will likely set some property, which will control which View gets shown (usually via Binding).
Sorry I can't get more detailed than this, but if I did I'd need to know more about your design, and I'd have to write a lot more stuff, which isn't really appropriate in this forum.