How can I expand the implementation of a wpf using my own custom classes? In particular, I want to create new C# classes on a wpf beyond the ones that derive from App.xaml and MainWindow.xaml. Should I add them directly on the project? If so, can I use references of the MainWindow elements inside them in order to tweak their functinality and add new tasks? Should they derive from the MainWindow class?
What is generally the most reasonable way to expand the implementation of a wpf to other new classes?
That is a rather broad question and where to place classes and from what classes to inherit are quite different problems. Both are ultimately a question of architecture though and what the right architecture for your application is cannot be answered here. It depends on what your application is supposed to do and how it should be done, all that should be planned out before doing anything with classes. You might want to read some smart book on topics such as software engineering and software architecture.
Ultimately you should get a good book on WPF, read it, and type all the examples into your editor. Simply trying to dive into an API with absolutely no example and no concept of how the architecture works is not going to get you anywhere very fast.
To answer your specific questions, though:
Should they derive from the MainWindow class?
No. To write the GUI for a WPF application, you rarely will have to use inheritance that isn't already written for you when Visual Studio generates a new app, a new window, or new user control.
It might make sense to use inheritance in your code somewhere, but rarely in the GUI code itself, and certainly not on the window or app level. The only manual use of inheritance will be for implementing custom WPF controls (the least frequent and most painful option for extending your GUI).
How can I expand the implementation of a wpf using my own custom classes?
It isn't clear what you're trying to do, so I'll try to cover all the cases.
UI
If you want a new application, usually you wouldn't derive from a specific application class at all, you'd just create a new WPF project (a whole program). Visual Studio will then create new classes for you that inherit from Application and Window.
If you want a new window, the same thing is true. You'd just tell Visual Studio to create a new window, and your classes would automatically be created for you, and they would inherit from Window.
If you want to add existing controls to a window, don't derive from anything. Go to the UI designer, and drag+drop controls from the Toolbox onto the page. Or edit the XAML for that window directly.
If you want to customize what happens when a user clicks on or works with a control, write event handlers for those controls. Or when you're comfortable about this, read up on data binding and the MVVM design pattern, since it will help you write cleaner programs.
If you're trying to customize the way your app or controls look, you'd usually use data templates, styles, user controls, and custom controls, in that order of frequency and difficulty. Except for custom controls, none of those involve manually written inheritance. When you add a User Control in WPF, Visual Studio will write a class that inherits from something, but you don't have to worry about that fact.
Non-UI
If you're trying to write the guts of your application, you probably should avoid writing any UI code.
It is a good practice to separate your UI from your main application guts. That way if a brand new technology comes out, you can strip off the UI, and throw the guts into a new program. Or if you decide to put those guts into a web page, that will also be possible.
You can reference this new code from the code-behind in the UI, or using the MVVM design pattern (which you should eventually read up on), but you should avoid mixing your UI specific code and your non-UI code as much as you can.
This means you won't inherit from any UI classes in order to implement the guts of your app.
Related
I have done quite a bit of research in the last few months and haven't been able to really find a good answer for my question yet:
A little background info: I am new to WPF and was asked to create a project using it. I learned most of the concepts on my own, but am struggling with one major issue. There is just too much code in the MainWindow class.
The reason there is too much code: There is too much code because all of the events for my UI Elements must be controlled in this one class.
Now I just recently discovered the use of partial classes. So I plan to split the events off into a seperate file. I am just wondering if there is any better way to decrease the size of my MainWindow class? I haven't been able to find a way to pass controls between classes, because I know it is not good to pass TextBoxes, or ListBoxes etc. between classes or methods. (I do understand, however, that you can pass parameters such as textBox1.Text or similar properties, but that doesn't fix my issue.
Introducing partial classes will not make your code any better, it will just spread the bad code over different files.
The "standard" way of developing WPF applications is to use the Model-View-ViewModel (MVVM) pattern. Using this enables you to have XAML-only views, view models that control their behavior and models that provide your application data.
There are tons of tutorials on this on the web. MSDN has a good introduction to this pattern. Having read this you should have a good overview of MVVM and can start applying it to your application.
I have a winforms app, I use a mix of standard controls and Syncfusion controls currently. In a few months or so new modules will be developed in WPF.
I'd like to add some state saving functionality. You know. TreeView x's last open node was y. Splitter X was split to point Y and so forth.
I've seen a few approaches. I've seen using the built in application settings and how to bind that to winforms and WPF. This has issues when your application is modular or the GUI is dynamically created.
I've got a few approaches in mind. I'd sort of like an approach which mirrors Entity frameworks POCO approach. I don't really want to be decorating my GUI code with attributes or deriving it from a special base class that knows about gui persistence, or implementing ISerializable, etc.
Saying that, I'm also considering using attributes to decorate the gui components and sort of duplicating a lot of what the serializable code in the framework already does, but specifically geared towards GUI settings. I also considered just using the serializable stuff, but it doesn't reflect my intent accurately.
Does anyone have any advice they can give on this?
Thanks
I was looking at creating a common control that I will be able to reuse on my pages: an AddressControl which has Address1, Address2, City, State, Zip, etc...
Originally I just created a class (AddressEntity) that contained all these items and implemented INotifyPropertyChanged. I included that class as a DependencyProperty in my Code-Behind for the AddressControl and used it as the DataContext for the bindings to its properties.
Then, someone said my code was ugly and I should look into MVVM. Looking at it, I assume that:
AddressEntity.cs will just be a container of data (i.e. Address1, Address2, etc.) and members (i.e. Clone, ToString, etc.)
I need some AddressViewModel to wrap my AddressEntity in and provide the PropertyNotification Changes, Validation, etc.
I need to somehow have a "View" for this.
The problem is every example I've ever seen has a UserControl as the View and not a CustomControl. Before I delve too deep into this...
Is it possible to use MVVM + Custom Controls for this example?
Is it pretty much the same thing (UserControl vs CustomControl) as the View with the exception of primary differences of UserControl vs CustomControl? Basically, is my CustomControl really just a View?
References: The Model-View-ViewModel (MVVM) Design Pattern for WPF
CustomControls are never done with mvvm.
What you want is a reusable view(user control) of your data and not a control(custom control).
UserControls and CustomControls are two completely different beasts.
EDIT:
Notwithstanding why UserControls were originally developed, in MVVM typically you use a UserControl when you want a reuseable view which is specific to your model/viewmodel. Its just XAMl without any code behind (except for the auto generated InitializeComponent stuff). Generally you keep a UserControl in the same project that you use it in.
You go for a CustomControl when you want a generic piece of functionality which requires a view and which has potential use even outside the scope of your current application. Here the control is actually defined in a code file and the look (which can be overriden) comes via XAML in a resource dictionary.
Generally you keep a CustomControl in a a seperate ControlLibrary project and reference the library in the project you wish to use it in.
With due respect to WallStreetProgrammer, choosing between a user control and a custom control based solely on whether or not you want a lookless control is a bit naive.
When using MVVM the Model and ViewModel should not be dependent on the View, that is they should not care what kind of view use them.
The difference between a custom control and a usercontrol in WPF is that the custom control is lookless and can be customized via its ControlTemplate. This is what you should write if you are writing a generic control library, like Microsoft does. If you however have a specific look in mind for you control, just go with a user control, it is much faster but will only have one look, the one you define for it.
It is common to use a mix of custom controls and user controls in a MVVM project. For example you would probably use a bunch of custom controls from Microsoft (like textboxes and textblocks) and combine them into user controls.
See Control Authoring Overview
I have a serious problem with nested user controls (UCs) in WinForms while trying to implement the mvp pattern (passive view). The project consists of one model (designed as a singleton) and a set of different presenters with corresponding view interfaces. To avoid one huge view interface and therefore an overloaded main UI, I decided to make use of a set of different UCs. Each UC has one view interface and one presenter that can access the model. But there are nested UCs: meaning that one specialised UC implements sort of a basic UC. The main UI just represents a container for all those UCs. So far, so good (if not, please ask)?!
There are two problems that I am facing now (but I guess both are of the same origin):
From time to time it is not possible anymore to load the UCs and test them within the Visual Studio 2008 User Control Test Container. The error message just says that a project with an output type of class library cannot be started directly etc. I can "handle" that by unloading all UC projects and reloading them afterwards. (I guess the references to all mvp components and other UCs are then updated).
Assuming that the implementation of my mvp pattern is okay and all those UCs are testable within the VS Test Container at a certain time - there is the biggest problem still left: I am not able to add any UC (even the basic and unnested ones) to a simple Form (UI).
Could it be that my basic UC causes all these Problems?! It consists of two simple ComboBoxes and implements a basic presenter and basic view interface. Whenever I add this UC to a different UC the VS designer adds two references to the public getter methods of the UC as resources. I then manually remove those resources from the resx-file and commend the corresponding lines in the designer file.
For the second one: You should use DesingMode property of the Component class (which UserControl derives) in your code. Be aware, there is a bug with this property not having correct value with nested user controls.
This can help you, I think: When your WinForms UserControl drives you nuts
A lot of times, I find myself doing UI control manipulation in the code behind and wanted to find a clean way of doing this.
Use Case:
A drop down has CSS1 style, editable in Edit mode but
has CSS2 style, view only in View mode
I can achieve this by simply have a set of switch case statements. I can use polymorphism and create a EditMode and ViewMode class but that requires me to have a reference to the UI control to be passed to these classes. This tightly couples the UI and the logic layer which I want to avoid.
Any ideas?
EDIT:
Can anyone give an example of externalizing the UI logic from the code behind?
Passing a control does not necessarily tightly couple, but I can understand the reasoning and would agree with it, as a general rule.
One option is to create the class as a UI class. This does not mean it has to be embedded in the ASP.NET web application, but rather that the library is set up as a web UI library. I do this by naming:
company.application.UI.{libraryName}
Your naming may be different.
In architecture, there is nothing wrong with having UI libraries that have polymorphic helper classes. I would not move these classes down to the business layer.
Take a look at Dynamic Data Web Application. There you can find one way to cleanly separate view controls from edit controls.