I have a winform application that I want to convert to WPF
It has a main form (MDI) and the children can call each other as well.
I read that MDI is not a good practice according to the mvvm. But I saw that application have the look and feel that I want (e.g:Prism- I was told that it is too complicated for beginners and for a small application like I need).
Do you know a small WPF project that follow the mvvm rules and has the look and feel of MDI application?
Thanks
Asaf
MDI is a GUI design pattern. MVVM is a programming design pattern. The two really aren't related at all. You can do either one or both together.
It is true, however, that many GUI design experts frown upon MDI but that's entirely because of usability for the end-user... not because of the underlying code.
Perhaps if you describe or provide a mockup of the UI you want to create we can provide guidance on how to implement it in WPF.
Related
I'm adding a bar manager and popup menu control to a Winforms application. I have to add the code to bind the menu to the manager, but I don't know where it would be best to do so.
I'll be using the designer heavily (company mandated) for the rest of the build-out, but the binding has to be done in code AFAIK. Currently I have it in the form load method.
I believe this is just fine to make it work, but I'm curious if you could put it in the designer code with the control details, or if it should go somewhere else in the code behind.
Hopefully this isn't an opinion based question.
Winforms doesn't make it very easy to separate things correctly, but you should try to separate as much as possible the UI code from the functional code.
Basically, you should try to put all your business logic in classes that are separated from your UI. Try to think that all that code could be used by another type of application, like a web app, or a WPF app.
The things that are in the codebehind should be only related to UI management, updating the UI and passing the changes to your business classes. There also seems to be some things that exist to have a MVVM or MVP on Winforms, check this SO question: UI Design Pattern for Windows Forms (like MVVM for WPF).
I was wondering, is there a consequence to embed a Windows.Form element in a WPF application ?
I don't really know the difference between both architectures, but mixing them can have negative impacts ?
There are always consequences with such choices.
Mainly winform doesn't support wpf event mechanism for bubbling event and dependency properties, you have to wrap it up if you want to use some binding and follow the MVVM pattern.
Besides, it will not be a part of the visual tree if I remember well. It will create an other form over the form of your application, i.e. an other window handle...
Not impossible, but You got to wondering yourself If it is worth it.
First of all, I want to let everyone know that I'm very new to the MVVM concept, and have looked pretty extensively for some explanation of what I want to do, but to no avail.
In the program I'm working on, I have a UserControl with a few buttons on it, which need to control the navigation of the main window. I have 3 different "pages" I want to be able to switch between in my main window. Instead of pages, I decided (for whatever reason, correct me if this is not the best approach) to use a UserControl for each page, and switch the visibility to the correct one. I need the data to persist while switching, so I don't believe that creating new instances of the Usercontrols will work.
My question is: How can I bubble the events from my "NavBarView" to the main window in a way that will allow me to switch the visibility, but in a MVVM way? I know I may be completely going about this the wrong way, and I'm happy to take any suggestions on a better way of achieving this navigation.
I have to use WPF, so WinForms is not an option. Too much transparency and custom controls for WinForms.
I would make the "NavBar" part of the main window if possible and use that to control the sub controls in the forms. I would be careful nesting User Controls. If you can avoid it I would (key indication is are you going to reuse it somewhere else). I took over a project a while back that had a main window with 3 separate highly coupled user controls that had to all work together and it was a nightmare. The only way I could get it to work somewhat safely was to have them all set their data context to the same view model. If I had to do it from scratch - would have taken a completely different approach with a single view.
Create own TextBox, Button etc control as own control using User control in C# Windows application, is this good idea?
I wanted make consistency for through out the application. Suppose if I want to change the Textbox border color then all forms textbox updated with this changes. It's just an example.
Please suggest me.
I don't recommend using UserControl just for consistency. If application skinning is what you are after, look into WPF. It makes it relatively simple to skin an application (or even a window, or smaller groups)
Here is an article on skinning with WPF: http://www.codeproject.com/Articles/19782/Creating-a-Skinned-User-Interface-in-WPF
Another alternative, staying within Windows Forms, is creating a class that inherits from TextBox, and using that class throughout the application. The Factory pattern would work well here. You could even adapt it to multiple skins.
It's not a bad idea to provide custom controls that match your "User Experience" (UX). It really just depends on what you are trying to accomplish with your program.
Am just creating myself a WPF application, like outlook. am having all forms seperately. I just want one main window and and am haivng navigation pane in left side. when ever i click items in pane, i just want to load corresponding form to the main window in right container. How i can do this?
Use a design pattern like MVP or MVVM..
Also you probably want to use the Command pattern which will benefit the maintainability of your UI related commands.
Tutorials:
WPF Patterns
This tutorial should get you started with these patterns. Paul Stovell shows how to implement MVP and MVVM and displays strenghts and weaknesses of each pattern.
OutlookBar:
This link should get you started with the UI part of your challenge. It shows how to use such a control and implement the Command pattern.
HTH