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
Related
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
I'm developing a desktop application that serves as an IDE for our customers. This application allows the user to configure and integrate our programmable devices into their products.
I'm looking for best practices/design patterns for managing persistent data in an MVVM app like this. Some data is potentially reusable between the users' projects, so I'd like to store those pieces independently, rather than in one big file. This scenario has led me to consider the way Visual Studio handles this (a .csproj file that points to the files that make up the project).
When considering the Visual Studio approach, I can easily implement an object like this for my own data and serialize it into XML. However, when it comes to opening and manipulating the files that this project file points to, I am really struggling to find an elegant solution.
For instance, I open my project file, deserialize it, and I'm left with an object containing the paths, as well as some metadata like CompanyName, ProductName, and so on. Next step: open/deserialize each of the files pointed to in the project file... But where should those objects live? How should you notify the ViewModels that the model was changed externally? Intuition tells me that there should only be one instance of any unique model to avoid issues with copies falling out of sync, but that's all I've got.
Perhaps there's a framework available for this?
There is probably a good article or SO answer to this, but I couldn't figure out how to search for it. Any advice would be greatly appreciated.
Settings that are specific to the application should be stored using the normal settings that's built into Visual Studio and .Net (Settings tab on project properties). This will provide you will versioning, upgrading, etc.
Settings that are specific to each project would need to be stored in the project itself.
To be a good corporate citizen, you should create a folder off of the user's Documents directory and then each project might have its own sub folder if it has multiple artifacts, or I guess just a flat directory if everything about the project is a single file.
The other part of your question was unclear. Are you talking about how a .cs file can be edited externally to VS and VS reloads it automatically? If so, you'd just set up a file change notification watch when you open a project.
EDIT:
View models should generally not have references to each other, unless you are referring to POCOs that implement INPC as a "view model" which I don't really. View models to me is basically the data context for a XAML view.
In terms of VMs communicating with each other, its best to keep it loosely coupled and use the messenger pattern. Most MVVM frameworks have a messenger implementation. You DI a IMessenger or whatever interface they use into your VMs and then IMessenger.Subscribe<OpenMessage>() (syntax obviously varies among MVVM frameworks, but in general you get a message of type X and add an event handler or call the send method) for example and get notifications of that type. The VM that is initiating the message would new up an OpenMessage and send it to the messenger to distribute it to the VMs that want it.
For your CsProj scenario, you would need to store those settings in the project file and deserialize.
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.
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 needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 9 years ago.
Improve this question
Looking for design pattern where-in my requirement keeps on changing or in another word i can say the requirement is not very clear.
I need to develop stand-alone Windows Forms App using C#. UI design of app may be changed as and when required as per requirement. Not sure from which design pattern shall i start.
Thanks,
Unclear requirements are the #1 reason for software project failure and delay! You simply can't build something as long as you don't know what to build. No 'design pattern' will help you here!
Facing uncertainty, you should generally go with agile programming methods and small components which are as loosely coupled as possible.
The best pattern for a project in which you know the requirements are going to change is SIMPLICITY.
Don't construct big systems to make your life easier now because they will make your life hard in the future. Not only will you have a new feature to put in, but you will have to unpick the system that is already there as it may not even support the feature.
I have been burned by this a few times - I was lazy (which is not always bad!) so i designerd a big, fun-to-code system to do the boring job for me. The requirements then changed and everything was now more complicated to debug and test.
There is no substitute for simplicity. For windows forms, consider an established pattern like model-view-presenter but don't burden yourself with it. Patterns are a means, not an end
Generally if something keeps changing it normally only effects 1 layer of your application, like the back end, the front end, the database etc.
If you can at least come up with the most constant constraints you can make your framework using dependency injection and loose coupling to allow you to change implementations at various layers quite easily. Its an open ended question so there is no 1 correct answer, however you want something which will let you swap out COMPONENTS easily, so design at the component level, not the the code level.
If you want a project management model which copes well with change look at Agile... or just be pragmatic...