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.
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
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 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...
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 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 8 years ago.
Improve this question
Can anyone help me how to do UI Automation in WPF? I want to check the operation of a Grid.
If you just want to automate WPF and NOT WinForms, check out Telerik's free framework. There's also a paid version if you want more features like record-and-playback.
Two open-source C# libraries that support automation of both WPF and WinForms controls are:
White
I've used this, and found it to not always be reliable.
QAliber
I've used this, and found it to be good but needing work.
Both are open-source, so they'll show you how to use Microsoft's API's, and you can modify them to meet your needs.
I've also used Coded UI Test and Ranorex, but they're both $$, and I don't care for record-and-playback because I feel it's a maintenance issue. (Although QAliber does have a record-and-playback feature and White also has an alpha-quality recorder.)
Of course you could always go it directly from Microsoft's API's if you really want to get down and dirty.
Use the tools built into Visual Studio - Coded UI Tests:
http://msdn.microsoft.com/en-us/library/dd286681.aspx
There are two methods of doing this: Record and generate code (tends to be a good starting point, but often doesn't give you reproducible tests), and manually coding them up via UI object tree.
I ended up doing the second option most often, because I liked the code I wrote much better than what the recorder functionality offered.
You can try PROJECT SIKULI:
Sikuli is a visual technology to automate and test graphical user
interfaces (GUI) using images (screenshots). Sikuli includes Sikuli
Script, a visual scripting API for Jython, and Sikuli IDE, an
integrated development environment for writing visual scripts with
screenshots easily. Sikuli Script automates anything you see on the
screen without internal API's support. You can programmatically
control a web page, a Windows/Linux/Mac OS X desktop application, or
even an iphone or android application running in a simulator or via
VNC.
Here is a good blog post to get you started on UI Automation:
Silverlight UI Automation Testing using Prism 4.0
It's Silverlight based, but the Silverlight is very close to WPF, and the UI Automation concepts involved are exactly the same.
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 5 years ago.
Improve this question
I have been learning about TDD and BDD and using this as much as I can at work but in an environment that really isn't agile.
I want to try it out properly on a pet project at home. So, going with the agile approach, and the principle of having working software, what should I write first? Should I create some forms first (this will be WPF / WinForms), linked to some dummy model? Or should I work ground-up. Any advice would be great!
EDIT
I know that I will be writing tests first. The question is at a higher level. Should I aim to put a working model and business layer together first or start with a form and a dummy model.
You are looking at it from a wrong perspective.
You are separating the application into components horizontally - UI component, backend component and so on.
Instead, you should look at it vertically - what are the different features - it could be login/logout, display list of users, display some other data and so on. Sort those slices into a priority order - which one needs to be done first, which needs to be done second and so on.
Then you concentrate on the most important slice until it works, whatever it takes - if it needs UI you add UI, if it needs backend logic you add backend logic and so on. Only after it is finished and fully working you go back to your list of slices, reevalute them, select the most important one again and concentrate on it.
Repeat until you are done.
This is basically what always working software means.
It allows you to stop at any point and say - this is good enough, and ship it.
If you work horizontally you will not have anything working until you finish all the work.
I usually start with the feature and area that is most important. Take a look at this SO answer.
If you want to do TDD/BDD you do start with tests.
In my humble opinion it is always good to start with model tests unless they are totally based on framework's functionality.
As for checking Controller/View part I prefer to have 'blackbox' tests which check if i get response I expect from an http request (for web applications). It allows to remove brittleness from the tests.
Even if I do full TDD test I often throw tests away if they are about nitty gritty parts of implementation, because otherwise very when refactor implementation at the end user experience is the same, so my application works fine, but I am spending hours fixing the tests. I don't to train myself to avoid refactoring just because I know the pain it would give by redoing a large body of testing code.
I would advice to test only things that really matter to you and ignore the rest till it bites.
When I do get a bug from something I was ignoring, I do write a test to document the bug even it it is about low level implementation.