As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
What are the top 3 main concepts in WPF that you need to understand in order to write good WPF code?
I think the most important aspects of WPF concepts are:
Templates and Styles (the way you define the behaviour and appearance of your application)
Data Binding (the way you should glue together your UI with your business objects
Declarative UI definition through XAML
Maybe there are other elements but in my opinion those are fundamental for WPF thinking.
I would say the single most important concept is the UI pattern Model-View-ViewModel, or as I like to call Model-View-ModelController. This is crucial to building apps successfully in WPF. Besides that, the real conerstones are Databinding, Templating, and Styles as others have mentioned. There is a nice post here on some common pitfalls to avoid when developing in wpf.
The real basics that you have to grok is:
XAML
Layout
Content model
Data binding
Their are loads more but these are the ones that has changed the most from winforms...
Also check out this thread: Interview questions: WPF Developer
I duno about top 3 but Attached/Dependency properties is pretty important.
I can only think of two big main concepts in WPF
In no particular order:
Bindings
Templating and Styles
When you have learned those two concepts, you will be able to write decent WPF code...
Oh, and the third would be XAML.. but that is the language... however, you might want to try to put as little in the code behind and as much in your XAML file...
Its quite easy to choose the code behind approach, but try to do it in XAML in stead...
The most concept in WPF lies on the stype and the behavior of the UI. It has lot of features, among them the following three are the most useful and important aspect.
Building the data binding of the business object and UI.
Changing style and more user friendly as to easy implement in UI so that the look and fill is good as user perspective.
Redefining the UI through the XAML and changing the font, style, implementing animation etc.
So its most powerful concept.
To know more about the technology, one should know about the architecture of a technology. However following are the basic but most important concepts in WPF are -
1) XAML
2) Rich Layout, Panels and Windows
3) Content model
4) Data binding
Related
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
I learning WPF MVVM pattern for couple of weeks already.
I still don't have clear understanding of this pattern.
I've read this topic https://stackoverflow.com/questions/275098/what-applications-could-i-study-to-understand-datamodel-view-viewmodel and almost all referenced articles.
The problem with all examples is that they have "a lot of extra stuff" (menus, several views etc. etc.) It's good when you need to learn how to do complex things, but it is not good when you looking for something you can start with.
I would like to have an application which I can use as skeleton to build my own application. I.e. I would like to see an application which has only absolutely mandatory things, that would be I suppose:
Main window
Model class
ViewModel class
View class
some ICommand implementation? (am I need something like that)?
probably I'm missing something
Part of the problem is, if you think about it, most of these aren't anything specific.
If you want only the "pure requirements", pretty much the only thing you'll need is some ICommand implementation. This is because the following are just standard WPF or C# classes:
Main Window -> Just use a Window
Model class -> This is your normal project data. Shouldn't be changed for MVVM
ViewModel class -> This is just a normal C# class that implements INotifyPropertyChanged
View class -> Standard WPF UserControl
The only thing you kind of need is an ICommand implementation that routes delegates to an ICommand. This can be ripped out of any MVVM framework (they all have at least one, but usually two implementations, one for Action and one for Action<T>, where the argument is routed from CommandParameter).
If you need a simple implementation of the command, you're welcome to steal the one from the code of my MVVM Series. The code for it isn't trying to be a "framework", since the goal was to show just the basics of MVVM.
Check out this video by Jason Dollinger on MVVM. It's a small example that goes through the process of creating a non-ideal implementation, and then how to do it properly using MVVM. I found it very useful when starting out on MVVM. I thought the video was solid enough that I didn't even need to look at the source, but that is available as well.
look at this cool toolkit
MVVM Light Toolkit
http://www.galasoft.ch/mvvm/
I wrote a very basic MVVM example here if you're interested.
When I first started learning MVVM I had the same problem you did... I couldn't find any simple resources to explain the very basics of MVVM. It was even harder when I was trying to explain the MVVM design pattern to someone else, so this was a sample app I put together for him. I thought it was fairly simple and straightforward, so posted it online.
Edit: The actual "MVVM skeleton" I usually use looks more like the code found in this link. The first link was an extremely mvvm simple app with a single page, however the 2nd one starts with an AppViewModel which can handle switching Views.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I just want to raise this question about WPF's User Control. I just started using this 'control' in my WPF applications, instead of 'adding' all my controls in one WPF window.
Anyways, would I get a faster process time if I use User Control? How about Dependency Properties? Can I still 'communicate' between my User Control and my WPF window?
What are your thoughts about it? Thanks in advance.
UserControls should be used for reuse, but this is not the main reason to use them.
the main reason to use useControsl is to seperate different parts of your xaml, so that each part is in charge of one responsibility only. for example, if you would write VisualStudio, you would create the ToolBox in one userControl, the CodeEditor in another userControl, etc. this is mainly for SRP, or Single Responsibility Priniciple.
Reuse, or DRY (Don't Repeat Yourself) is important, but SRP is WAY more important.
As to communication - yes, you would use dependecy properties.
The main reason to use UserControls is to bundle a set of controls so they can be reused (normally within the same application)
As for 'performance' you are adding an extra node to the visual tree so it would be slower but that will be hardly noticeable.
Communication between a UserControl and the window (or its parent) is completely similar to any other control you add to a layout class.
I only use UserControl when it's need to share group of controls between two or more places. To communicate between UserControl and Window you should implement DependencyProperty -ies in your user control. It's disadvantage. So, when it's possible I avoid using UserControl and use it only, for instance, to share layout between two versions (WPF and XBAP).
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.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
This question intends to provide a list of solutions to common pitfalls, "gotcha's", or design issues when developing WPF applications. This can also include proper design-patterns as long as there is an explanation as to why it works best. Responses should be voted up or down based on how common the type of issue is. Here are the rules:
One response per post. This will clearly give the most common issues the highest ranking.
It would be best to provide the link to the a related post or solution already living somewhere in SO land.
Problem : The major issue I have seen so far is that people start coding in WPF with the winform UI model in mind.
Solution: WPF is not WinForms/MFC/Win32 So Forget all the UI side assumptions and norms you have used and learned while developing Windows based UI for last 20+ years.
It is very important to understand the core ideas behind this platform, This link- Major UI Development Breakthroughs in the new WPF platform will give an in depth view of WPF. Which lists out the following points. The highlighted ones are my favorite features of this platform.
Advanced Graphics
Drawing Object Model
Rich Application Text
Adaptable UI Layout
Flexible Content Model
Lookless Controls
Data-Driven UI
Consistent Styles
Triggers
Declarative Programming
Not realising how bad the font rendering is at the start of a project and being told by the client they can't stand looking at it because of how fuzzy everything looks.
Problem: Using the M-V-VM design pattern, where do I instantiate the views? Does this happen in the ViewModel? SO Question 1, SO Question 2
Solution: WPF development is most effective when using the M-V-VM pattern as opposed to other common patterns such as M-V-C. The tendency is to treat the ViewModel the same as you would the controller which would handle opening and creating views as well as the models. This is not the case in M-V-VM. Views are the only place where are the views should be created. The ViewModels should know nothing of the view. SO Answer 1, SO Answer 2
Problem/Question: SO Question
How do I expose a DependencyProperty
of a component in my user
control to users? There are plenty
of examples of how to expose a normal
property by creating a new dependency
property and binding, but none on how
to expose a read-only property like
FrameworkElement.ActualWidthProperty.
Solution: You need to expose a new Readonly DependencyProperty in your user control, and update it whenever your contained "component"'s ActualWidthProperty gets updated. This requires using DependecyPropertyDescriptor to get notified of changes that occur. SO Solution
Getting data binding to work properly between properties defined in ContentControls (Windows, UserControls, etc..) and properties on elements that make up the controls content. For example. Let's say I have a Window that looks like this:
<Window x:Name="MyWindow"....>
<TextBlock Text="{Binding Path=PropertyDefinedInMyWindow}" />
</Window>
Problem: No matter how often you update the "PropertyDefinedInMyWindow" it never gets reflected in the TextBlock. SO Question
Solution: You need to set the DataContext of the Window or tell the binding which element the property lives on. SO Solution
Ivan Towlson did a really good presentation on this topic. Most of the information is in his slides, which you can get from here:
http://hestia.typepad.com/flatlander/2008/08/codecamp-2008-.html
Using code - behind in views, which makes baby FSM cry.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
Does anyone have any experience with a good wpf pivot table control?
DevExpress Grid control has good pivot functionality. Used it for Winforms a lot. I think the WPF version is also available.
The Xceed WPF Grid looks like it has a lot of great capabilities. We use their WinForms grid and it does a pretty good job. They have a demo app you can download that shows off the different ways you can use the grid.
VIBlend's data grid control has pivot table capabilities. I'm not sure if they have a WPF version but you can certainly host WinForms controls in WPF. Another alternative is to try hosting the MS Office OWC.
If possible, I also need to be able to drag column headers and make them row headers and have the data summarize and group accordingly. Something along the lines of old ActiveX DataDynamics Dynamicube.
http://www.datadynamics.com/Products/ProductOverview.aspx?Product=DC
Auto Summary, Filtering of the Data Items being used, etc. without having to write a lot of code to do it in a custom fashion.
Alternative:
Excel OWC is a great query and reporting tool if you are running OLAP. It's a little dated and poorly documented, but works well on the intranet and can squeak by over the net.
http://msdn.microsoft.com/en-us/magazine/cc164070.aspx
I would suggest WPF Toolkit which can be downloaded from DatGrid available in Codeplex. This is compatible with the latest WPF(.NET3.5 SP1) which is free and have almost all the features for a general purpose(and even more than that) But there are commercial vendors who have good grid controls(Not really free). Like Xceed, Infragistics, Component One, Telerik
Currently there are no WPF Pivot Grid controls. The vendor most likely to have it, DevExpress does not yet have a WPF version of the XtraPivotGrid.
Your best bet is to use XtraPivotGrid hosted inside your WPF control.
The other thing you can do is to use another grid vendor and do the "pivoting" by using LINQ or by manipulating the DataTable manually.
DevExpress Pivot Grid for WPF is almost ready. It will be released in the first half of the year.
I am a consultant at Infragistics and I've been working exclusively the last few weeks with the Infragistics XamPivotGrid. We've been working to make this control fast and memory efficient. As a user and a developer, I am highly impressed with the usability of this control. You can check out this control in the WPF and the Silverlight NetAdvantage Data Visualization products at www.infragistics.com!
:-)