Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 4 years ago.
Improve this question
Introduction
I know this is a very basic question, but I've spent quite some time reading or watching online tutorials, but I simply can't fully grasp how to properly implement a MVVM pattern in my project. I know how to set up a WPF Project using MVVM, but I don't know when and where I should use it.
Problem
I am currently tasked to set up a WPF Project. Since I never worked with WPF before and had a lot of issues with my bindings - due to not understanding MVVM - I made the mistake of trying to solve most of my problems in code-behind, ignoring the XAML file as good as I could. This backfired ever since and I'd like to rework my code. However, before I can start I need to understand why my Bindings won't work and how to fix it.
My current Project consists of:
1 main UserControl using MVVM which displays 4 panels
4 UserControls as Children of my main control without MVVM. One for each panel
2 Windows without MVVM created from my main Control
a Couple of extra classed with helpers and some other stuf
I originially only split up my main user Control, because my c# code to calculate the content of my panels grew quite large and I thought this might help to keep my project more clear, but since i couldn't get the bindings to work in my sub-controls, I simpy set them in my code behind instead of using xaml. I've seen other projects with a single MVVM UserControl, which contains thousands of lines of code behind, while its child contols contain some events at best. Is this how it is supposed to be?
My Questions
What needs a ViewModel? Do I need a ViewModel for my Child Controls? Do I need a ViewModel for my Windows? When do I need a ViewModel, when not?
What belongs where? Is it generally wrong to write C# Code in Child Controls without ViewModel? What is the best way to keep my code small?
How to bind? I can bind DependencyProperties in my Child Controls, but creating a DependencyProperty in my main Control for something that's only used in a Child Controls seems redundant. How do I set my DataContext for Child Controls?
Thanks for your help.
I think this Tutorial comes closest on what i was looking for.
It explains most of my problems regarding Bindings and is a solid base for me to work on.
I don't know if I am supposed to post this as an answer, but since most of my issues are addressed by now, I wanted to close this question.
Related
Closed. This question needs debugging details. It is not currently accepting answers.
Edit the question to include desired behavior, a specific problem or error, and the shortest code necessary to reproduce the problem. This will help others answer the question.
Closed 11 months ago.
Improve this question
I have a VERY SIMPLE application which is supposed to read a file selected by the user and display it on the screen. For that I created two views, one with a button for the user to select the file and another view for displaying the contents of the file.
I also have two ViewModels one for each of the views, now, when the user clicks the button to select a file the code in the ViewModel will use OpenFileDialog and open the file, my question is should I call OpenFileDialog from the viewModel or from the Model for a MVVM project?
Dialog boxes don't fit into the MVVM paradigm very well, due to the tight coupling they have with the OS. As a general rule though, anything you want directly unit-tested belongs in the view model, while anything that creates Windows GUI objects at runtime belongs in your view layer. With that in mind, the view is the appropriate layer for calling OpenFileDialog. You may find that you still need to break the clean MVVM architecture to do this, so abstracting it away into a service that can be injected will at least keep it away from the rest of your code and maintain good seperation of concerns.
If you really want to do this properly then you have to implement some boiler-plate code similar to what the WPF team wrote for "regular" windows. I wrote a long article about it here, along with a library for easily adding dialog box functionality to your own MVVM projects:
https://www.codeproject.com/Articles/820324/Implementing-Dialog-Boxes-in-MVVM
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
I wasn't quite sure how to title this question or even ask it really, but I will do my best.
I am building a diagram/flowchart style designer which involves (from a very high level) a toolbox of controls, connections, connection points, overlays for editing,etc.
The controls are backed by business objects or components. (i.e. there might be an 'Accounts' components which is represented by a 'Accounts' UI/View component.
Below is a sample mockup of what I am mentioning above.
This is nothign out of control and hundres of applications have similar functionality.
I already have a working version of this (more-or-less), but it was done very poorly by myself (in my opinion) and in order for us to be able to make this extensible so that I can continue developing it our horizontally (additional toolbox support), I need to refactor and do this cleaner.
I have been referencing some articles on common GUI Architectures such as MVP, MVVM, MP, PV,PM,etc.
My concern is that everything I have read so far is very closely related to defining GUI Architectures for CRUD operations. None of these really discuss complex UI library design.
I have been able to find a few articles that give some 'Best Practices' on this topic, but its really not much for me to continue off of.
Thus far, MVP is the closest to what I would imagine would work for this, but I am just not convinced enough to go down that route.
It may not help much, but I figured I could give a brief list of some of the interactions/behaviors that need to be accounted for. Nothing out of the ordinary of what you would see in a diagram or flowchart application.
Controls (backed by business objects, most likely just a reference to the Type to be created at a later time) can be dragged from toolbox to the designer canvas.
Controls can be dragged, removed, and have their state modified (business state).
Connections can be initiated between a source and target component.
Connections can be moved (at both ends) between a soruce and target component.
Multiple designer windows can be open, so we will have to maintain the concept of 'active' designer.
I am still not sure in the case of designing this where I would want to maintain the UI state/logic as well as the business state/logic. Additionally, where would the concept of the 'active designer' be maintained,etc.
UPDATE Apparently, this is another target for SO trolls, so I will try to clarify my question/post.
I am somewhat knowledgeable on the different patterns that are applied for UI design, however It seems they are not versatile enough for library design of complex UI Components. I could be wrong in this. What I want to know is in the case of this particular scenario, from what was discussed above, am I wrong in assuming that going down the route of MVP might not be able to account for complex UI logic?
All patterns at this level (MVP, MVVM etc.) are suited for pretty much any complexity you'd need. What it can handle is only up to you, you must understand it's still just a pattern, not a framework with some pre-made functions you'd have to use.
Whatever you do however, pick WPF over Winforms, especially when you need complex control over UI.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
I am attempting to program a robotic arm, I have a C# project with many different classes running as a Console application that permits the robot to move to various places and to do certain tasks. The robot does not have a vision system.
On to the problem:
I am using a kinect sensor to extract color and depth data in a WPF application (I am following a Kinect tutorial which does this) which the robot will then use to move to certain positions. The only problem is I have a separate Console application as mentioned above which has a heap of classes and functions. In the WPF application an event fires when all sensor information is ready. I want to place my entire Console Application code in the infinite while loop of the WPF project and then use the sensor information to then get the robot to move to certain locations.
Essentially what I am asking is where can I place code into the infinite while loop of the WPF Application ?
I think I might be completely misunderstanding how to use WPF applications, any help would be greatly appreciated.
I think you're misunderstanding how WPF is supposed to work. WPF is not supposed to be the structure in which all your code runs, it is supposed to be the layer which DISPLAYS your system. That is to say, that rather than "inserting your console application" into WPF and expecting WPF to do the leg work, you should put WPF on TOP of the console application.
Take a look into the MVVM pattern to see what I mean.
a quick google for "Introduction to MVVM" gave http://www.infragistics.com/community/blogs/anand_raja/archive/2012/02/20/the-model-view-viewmodel-101-part-1.aspx
For reference, your existing console code would fall into the model layer.
In very brief:
Model - your system, with NO LOGIC of how the system is displayed or used
ViewModel - a middle man layer that effectively defines how a user interacts with your system
View - a very thin, implementation specific version of your UI.
MVVM is the default pattern for WPF and you'd be wise to look at implementing this using those principles.
If you just want to migrate your code, you can add it to the code behind file for your main window control. This is considered bad practise in WPF, but it is the quickest path.
This is more like winforms programming so you have a constructor from which you can call other code.
If you're looking at infinite loops though, you might want to wrap that up in an async await Task method See MSDN - otherwise your UI will freeze up running on the same thread.
Hope that helps.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
I want to build a management system using Windows Presentation Foundation. I know there's Expression Blend for Graphics design and VS for C# code.
my question is, should i build all UI first using Blend (Buttons, Windows, other elements) and then writing all code (Data bindings, database connections, etc.) or should i build it one step at a time ?
It's my first time using this tech, I've used Windows forms in the past and i want to implement some good-looking graphics in my app.
WPF is intended to make following either UI-first, code-first, or parallel approaches possible - particularly with an MVVM architecture.
However, I suggest starting by putting together a vertical slice through all layers of your application. Reality tends to bite, and depending on how you put your architecture together you will undoubtedly come across many issues that impact your chosen approach.
Since UI is important to you, "Blendability" (the ability to use blend alongside a VS solution) is likely to be a requirement. In this case, you'll want to research carefully how to create a solution structure that will support this.
I think you should take it one step at a time. Don't worry about too many frills in the UI, you can always add to it more later. Keep in mind how you want it to look, and afterwards you can create better looking styles etc. in Blend.
I personally use Visual Studio for most of my development, even the UI. I use blend for creating templates or styles mostly. It used to be that blend was superior to Visual Studio in the designer support, but with VS2012 it has gotten quite good. Also, Blend has a learning curve, it would take some time to get used to. Since you are new, I would suggest not overcomplicating things for you.
The number one thing you need to know about WPF vs. Winforms is complete separation of UI/App logic. It is often much easier to create "ViewModels" with properties and bind those properties to the GUI. If you try to get too involved manipulating GUI elements from code, you'll start digging yourself into a deep hole. The GUI should be databindings, triggers, behaviors, templates, etc.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 2 years ago.
Improve this question
For Quick learning WPF,I am following few books of WPF.But I don't know how to start it and which steps I have to follow to get Quick knowledge on WPF Programming with C#
Try to think of interesting and useful projects. I suggest a charting library with data-binding support. You will learn many important notions like:
Composing elements in a container
Creating custom dependency properties
Providing data-binding support for the list of points to draw (for example), using INotifyCollectionChanged interface
Using fast rendering techniques to plot thousands of points (look for DrawingVisual class)
And most importantly: you will learn to create your own components that suit your own needs, instead of always relying on existing ones.
Resources
Interesting (must read !) resources that are not always documented in books:
WPF Apps With The Model-View-ViewModel Design Pattern, Josh Smith
http://msdn.microsoft.com/en-us/magazine/dd419663.aspx
Writing More Efficient ItemsControls, Charles Petzold
http://msdn.microsoft.com/en-us/magazine/dd483292.aspx
Using DrawingVisual Objects, MSDN
http://msdn.microsoft.com/en-us/library/ms742254.aspx
There are a lot of tutorials on WindowsClient.net, head over there and go through all of them. After that you might want to consider studying for the MCTS / MCPD in Visual Studio 2010 for Windows Development, that will certainly get you on the right track.
"WPF 4 Unleashed" by Adam Nathan.
You don't need anything else.
Follow the MVVM pattern
Don't use code-behind unless you really have to
Try and keep all your logic in your ViewModels
Try to make your views dumb, so that they only concern themselves with presentation
Create standard control styles and templates and push them into resource dictionaries so that most of the XAML in your Views is plain and simple
Use (and study) a good WPF Framework such as Caliburn Micro which will push you the direction of best practice
Pick up a copy of Pro WPF in C# 2010
Online tutorials. What helped for me was doing some WPF with F# tutorials that were based off Petzold's book. They started off doing everything programmatically without designers, and without xaml, and I learned xaml later.
But that is just me. There are a lot of online tutorials out there, that will probably be quicker, yet less thorough than books.
What books are you going through, and why are you having trouble starting at the beginning?
Nice article to start:
http://msdn.microsoft.com/en-us/magazine/dd419663.aspx