Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 11 years ago.
Improve this question
As the only developer in our organization who has used WPF for the last couple of years, I've been asked to give a talk about it to other developers. I was hoping people could suggest how much and what I should cover without making the other developers feel overloaded.
- The presentation is only for around 30 minutes
- The rest of the group are all Win Forms developers and some have experience working in Silverlight
Show them data binding. It is the one of the most important things to wrap your head around in WPF, and it's also one of the great advantages it has over WinForms.
I would start off by showing some visual examples of what can be achieved through WPF and then describe, using diagrams, how that was achieved.
One great example is the fact you can bind the UI directly to a model - whether this is simply a runtime data type, or something hooked into a back-end database. Just the fact that you don't have to write custom UI update code to re-populate UI elements (like in WinForms) every time the backing data has been updated; is something that sells it for me!
On top of that, you have the whole styling system. It is much easier to mould the appearance of the application to something that your company wants. And it looks much nicer. For example, with the composition rendering system, layers of controls can be transparent - allowing you to create circular buttons where the click area isn't actually a rectangle. Similarly, though perhaps not applicable to you, is the fact you can overlay WPF controls onto a D3DImage, which can be used to render 3D content to. So you can have an application built over the top of some 3D imagery.
I would suggest reading through some topics about WPF on MSDN. Refreshing yourself over some articles on there may help you identify some really cool aspects of it.
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 7 years ago.
Improve this question
What should custom controls and even to change some application styles when it comes to, for example, change the thumb of a slider or add multiple thumbs to the slider bar. In web development, people usually have a guy
I have 1 year of experience working with WPF, but it still looks hard for me when it comes to custom stuff.
dependency properties.
In my opinion to be a good "Frontend" WPF developer there are some key concepts that you should master, I may mention :
1 First of all :
XAML
2 Second of all :
Styles.
Resources.
Logical/Visual Tree.
Dependency Properties.
Binding
Animation
Triggers
VisualStateManager
Optional : Learn how to manipulate Blend
3 Learning a good architectural design pattern :
MVVM : here you have multiple choices, you can :
Go on your own : and MVVM your applications alone.
or
Choose some 3rd party helper libraries such as : MVVMLight, Caliburn.
or
PRISM for large complex lob apps (can be used for simple apps too though)
Concerning your own controls, there are two options :
Custom Controls
User Controls
As you are going to use XAML most of the time, XAML as any other programming language has it own right way of doing things, it has its own patterns, I strongly advice you to take this Pluralsight course called XAML Patterns course, this will help you understand more WPF and XAML and know exactly the spirit of this technology
I would say you need to adhere to the MVVM (Model-View-ViewModel) design when it comes to creating a good WPF application. Its specific intent is to separate the view and and model (data) concerns.
The easiest way to follow MVVM in WPF is to use Caliburn.Micro and Fody.PropertyChanged
If you want to see what a complex application looks like caliburn.micro. have a look at the code for the gemini framework.
In short; MVVM is the way to use WPF, Fody automatically deals with INotifyPropertyChanged, and Caliburn Micro makes MVVM very easy to implement.
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
Why is having some code behind for doing simple operations such as opening or closing a dialog a bad design choice when using MVVM? If not for code behind, then where is the consistency for handling such a simple problem such as opening a dialog in MVVM?
I know this subject has probably been beaten to death and using "Code Behind" in WPF has been getting a lot bad rep over the years. I just want to make my point here and hopefully it helps someone gain a different perspective on the problem.
I think most people would agree that the MVVM pattern while a little bloated encourages reuse and better testable code. Separating business logic from the view is not a new concept but yet many people still don't do it. MVVM and WPF makes this separation a bit easier through the concepts of data binding and allows your ViewModels and business logic to be tested independent of the view.
Where it breaks down is when the developer needs to do simple things like opening or closing a dialog. Outside of MVVM, a developer could just instantiate the view, assign the DataContext and call ShowDialog. But in MVVM, a developer's first thought always goes to what's the common pattern here for opening/closing dialogs through MVVM. And what do they do, they take their question to Google/Bing/StackOverflow. And sure enough, they find answers to their question but the problem is there is no consistency here for doing such a simple operation. Some people want to use Mediators, others a dialog service, and others want to bring in Prism. Just about everyone has their own home grown implementation and all to accomplish what? So that they can avoid having "Code-Behind"? To me that is just sad. We've basically taken something that is so simple to do and added abstractions and indirection to try to solve the problem. The gain is so small it's not even worth it. Without going through this level indirection, you can still reuse your ViewModels with other Views, and you can still test your ViewModels in isolation. The only thing you don't get to test is a couple lines of code that opens or closes a dialog.
The MVVM and unit testing purists will think this is blasphemy. But remember, in the end, it's really your decision on how complex you want to make your application. To me the simple solution is usually the right solution.
Why is having some code behind for doing simple operations such as opening or closing a dialog a bad design choice when using MVVM?
It's not and anyone who tells you otherwise does not understand the central objective of MVVM.
If not for code behind, then where is the consistency for handling such a simple problem such as opening a dialog in MVVM?
Consistency regarding a specific problem is not something a general pattern like MVVM can or needs to provide. There is no right way to do it, among other aspects there are simply ways that violate the MVVM and those that do not.
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
What kind of questions would you expect someone to know during an interview for a job doing WPF/Silverlight development?
Entry Level
Strong .NET 2.0 Background & willing to learn!
Explain dependency properties?
What's a style?
What's a template?
Binding
Differences between base classes: Visual, UIElement, FrameworkElement, Control
Visual vs Logical tree?
Property Change Notification (INotifyPropertyChange and ObservableCollection)
ResourceDictionary - Added by a7an
UserControls - Added by a7an
difference between bubble and tunnel routing strategies - added by Carlo
XAML
Mid-level
Routed Events & Commands
Converters - Added by Artur Carvalho
Explain WPF's 2-pass layout engine?
How to implement a panel?
Interoperability (WPF/WinForms)
Blend/Cider - Added by a7an
animations and storyboarding
ClickOnce Deployment
Skinning/Themeing
Custom Controls
How can worker threads update the UI?
DataTemplate vs HierarchicalDataTemplate
ItemsControl vs ItemsPresenter vs ContentControl vs ContentPresenter
Different types of Triggers
How to do Animations through StoryBoards
Advanced
Example of attached behavior?
What is PRISM,CAL & CAG?
How can worker threads update the UI?
WPF 3D - Added by a7an
Differences between Silverlight 2 and WPF
MVVM/MVP - Added by a7an
WPF Performance tuning
Pixel Shaders
Purpose of Freezables
Rest here : Interview questions: WPF Developer
Off the top of my head:
What is a Template, and why are they used.
How does WPF/SL manage resources in XAML
What is the "x" xmlns
What are markup extensions
What is data binding, talk about it a little, tell me why it's awesome
How do asynchronous calls work in Silverlight and what considerations must you take into account (if any) when working with them?
What does it mean if a control is virtualized?
What tactics can be used to reduce the initial XAP download? subsequent downloads?
What is isolated storage? How much of it do apps get? Can they get more?
What features are only available when
using Silverlight Out of Browser?
Explain how the Print functionality
works in Silverlight 4? and any
issues you can think regarding it?
What are the different ways
Silverlight can access Services?
This site has some useful questions for basic Silverlight Knowledge - http://www.codeproject.com/KB/silverlight/QuestionsOnSilverlight.aspx
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
Okay, to give a little background, I learned WPF about 3 years ago and have kept reasonably up to date with what's happened since in various different versions. I looked at (and implemented) MVVM on a couple of projects, had a good look at frameworks like Prism so I think I'm pretty well versed in most areas of the framework. I've also worked briefly on a couple of small Silverlight 2.0 projects.
My problem is this, I'm about to start a Silverlight job at a new company and while I'm very comfortable that I can do the job well, I feel like my WPF knowledge may cause me some issues. I've gone over the WPF/Silverlight guidance white-paper on codeplex which is excellent and really helpful but although it highlights the differences that still leaves me wondering how to get around those differences.
For example, I know that DataTriggers are missing as areMultiBindings and a whole array of other stuff. What I'm interested in reading about is not the differences per se but how you get aronud those differences or what other patterns are useful in Silverlight. What if I need a DataTrigger? clearly my design should take these things into account.
So, the question is,..if you've gone through this transition, what differences caused you the most trouble and how did you get around it?
First, while this is dated to Silverlight 3, this white paper goes through the differences between WPF and Silverlight in detail:
Microsoft WPF-Silverlight Differences White Paper
http://wpfslguidance.codeplex.com/releases/view/30311
That is a great first step to familiarize yourself with the differences.
You might also want to take a look at the Prism project. One of the goals of this project is to build a set of interoperable functionality between Silverlight and WPF so you can essentially build enterprise applications that target both platforms and reuse the majority of code. Familiarizing yourself with the project will help highlight differences as well:
http://compositewpf.codeplex.com/
Finally, while Silverlight might not have data triggers, you can use a combination of features such as behaviors and triggers:
http://www.silverlightshow.net/items/Behaviors-and-Triggers-in-Silverlight-3.aspx
And the Visual State Manager (VSM):
http://timheuer.com/blog/archive/2008/06/04/silverlight-introduces-visual-state-manager-vsm.aspx
To accomplish most of what you need.
Giving a Silverlight port per se for our WPF App, the following are the two 'pain' points we encountered.
Splitting up and grouping XAML's/modules for improved performance and on demand XAP downloading using MEF.
Challenge of achieving Binary Compatibility using the same code base for WPF/Silverlight.
A few of our Functionality required OOB and user acceptance.
We optimized a bit of Functionality relying on IsolatedStorage.
Hope this helps.
[ Now that Silverlight 4.0 has a stable build, we had a few Visual Studio hiccups over the last few releases which resolved itself overtime. (We stuck to Silverlight 3.0 and somewhere in mid march jumped to SL 4.0 beta and final release)].
N.B. : I have tried to keep things way abstract to not reveal the identity of the client.
MarkupExtension
IMultiValueConverter
Template.Triggers
Style.Triggers
Binding RelativeSource={RelativeSource AncestorType...
Binding.IsAsync
{x:Static ...
{DynamicResource...
Grid.IsSharedSizeScope / SharedSizeGroup
All of these are not supported in Silverlight and you have to workaround them.
Every case needs it's own judgment about how to "fill the gaps"
For the triggers part, the only solution is to use VisualStateManger.
The following article gives a good example of how to make the transition from triggers to VSM: http://blogs.msdn.com/b/wpfsdk/archive/2009/02/27/the-visualstatemanager-and-triggers.aspx
Next, OnApplyTemplate is fired in different order, which might affect any Custom Controls or UserControls you might have created.
WPF:
UserControl Constructor
MyControl Constructor
MyControl.OnApplyTemplate
UserControl Loaded
MyControl Loaded
Silverlight:
UserControl Constructor
MyControl Constructor
MyControl Loaded
UserControl Loaded
MyControl.OnApplyTemplate
And of course Microsoft has an article about that, called "WPF Compatibility" and gives a more thorough overview about the differences and changes between WPF and Silverlight:
http://msdn.microsoft.com/en-us/library/cc903925(VS.95).aspx
Hope this helps
Silverlight forces you to make some changes to your design patterns, which, if is pervasive throughout your software, can render code reuse quite moot.
For instance, data template selectors are missing -- I found this to be quite a shock.
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 2 years ago.
Improve this question
I am rewriting my windows forms based application and I am going to use WPF.
The application relies heavily on drag and drop techniques, in a very graphically environment. The uses "Design" reports etc. by dragging elements onto a grid, moving them, right click setting properies etc. all of which is saved to a database. Also control program flow by drawing flow charts, with routing and desicion making, all drawn on the form, and again save to a database.
Does MVVM lend itself to this kind of application, or am I trying to fit a round peg in a square hole.
Your thoughts are appriciated.
My take is to use MVVM, but not religiously.
I mean, use a model to your views, but also use some code behind when needed (drag&drop, double-click). Find a balance that helps your development, without driving you nuts.
MVVM lends itself very well to WPF. Can you do drag-drop with WPF and MVVM? Sure you can. Try searching for "WPF Drag Drop Behavior"
There are two really good reasons to go with MVVM:
It helps you produce business logic
and data access code that is more
easily unit tested
With very little extra effort, all
of your UX should be easy to modify
in Blend
As several posters have metioned, any eventing related to the UX can be handled in code-behind, but you should be exposing and accessing (read and write) data through your View Models for easy binding in your Views.
As for the extra effort I referred to in #2, you could easily add a static property to your App object to determine if the application is running versus a View being opened in Blend. If the View is open in Blend, leverage mock data instead of making data access calls. Here's some sample code that works for checking if Blend has a View open:
if (Application.Current == null || Application.Current.GetType() == typeof(Application))
{
isInDesignMode = true;
}
else
{
isInDesignMode = false;
}
Hope this helps.
If you are looking for application maintianance and testability in the long term, sure you can do that stuff with MVVM and WPF. or else just go with WPF. MMVM initial learning curve is very steep.
Patterns like MVVM is to make life simpler. So for any case if you feel like the pattern is giving you a hard time, feel free to break it or try something else. Blindly following anything will not help you. But anyways MVVM also supports complex UI interactions like Drag and Drop, I believe behaviors could help you on this. Search on google for WPF drag & drop behaviours and you could find a lot of tutorials and code to assist you on this.