Related
I am planning to learn XAML. I wanted to know if I should first learn about WPF and then start XAML?
Please advice.
It depends on what your future plans are with XAML/WPF. If you want to get up and running and use it as quick as possible you might consider starting with XAML and WPF at the same time (but note that you can't learn or use WPF just be learning about XAML).
If you plan to work with XAML/WPF for a long time and you will have a lot of WPF projects ahead you probably should consider starting with "pure" WPF.
I belong to the latter camp and it helped me a lot to first get to know the WPF object model, rendering and layout system and then start with XAML, styles, templates etc. For me it made thinks easier to understand (and there is a lot to understand). I understood that XAML is just another way to represent/serialize a .NET object graph that is built as a layer on top.
This is also the way Charles Petzold's book is structured and I think it is the perfect book to start with when you want to get to know WPF really well.
Its not a good question but WPF applications are is built on XAML. I started learning from WPFTUTORIAL
You will find that you will are likely to learn both at the same time. That said, XAML is a designed to be a mark-up language and is used for several technologies, e.g. WPF and WCF et. al.
As #bitbonk mentions, several books on the subject first give you an introduction to WPF (Dependency Objects, Visual Tree and Logical Tree, Controls, etc) before showing any XAML markup.
Whatever you do make sure that your first 2 or 3 applications are throw away apps (not production code). I have seen way too many developers code themselves into a hole when learning to code with WPF. I would recommend studying the MVVM pattern as well. This is critical to building stable WPF applications.
Here are some blog posts I have written that may be of some assistance.
http://tsells.wordpress.com/category/mvvm/
I've been developing with WPF for many months now. It's a great framework and I'm able to do fancy, elegant stuff that would have been a lot more difficult with WinForms.
However, I do have the feeling that for normal "line of business" type of applications without any special UI requirements, it still takes me longer to code the UI in XAML than it did to drag-and-drop it in WinForms.
For example, in WinForms, I would just drop an additional label and an additional textbox on the form and arrange everything (using the helper lines) until it looks nice. In WPF, I'd start by factoring out the properties of the existing label and textbox into a style, so I can reuse them; think about the most suitable layout element, maybe refactor some dockpanels/stackpanels into a grid (or vice versa); try different values for the margins etc. Although I have a lot of experience in WPF, it still takes a long time.
I know that I could just forget about "clean XAML" and use the GUI designer in Visual Studio 2008 (which just absolutely positions everything inside a huge grid), but I fear that I would lose a lot of the advantages that XAML offers by doing that.
Have you experienced something similar? If yes, what did you do to speed up everyday WPF development?
What I do to speed up everyday WPF development:
Ignore look and feel for as long as I can. Ideally, tweaking alignments and margins and defining styles is the very last thing I do.
Use the DockPanel before using a Grid, and a Grid before using a StackPanel.
When using the Grid, star-size everything. I'll come back and fix this later, but during prototyping, having a clear idea of how many rows and columns the Grid actually has is enormously helpful.
Prototype in Kaxaml, finish in Expression Blend, test in Visual Studio. Figuring out a methodology for this has taken a lot of time, and it's still very much a work in progress. But Kaxaml is great for quickly seeing how a XAML prototype will behave, and Blend is great for working out the visuals and encapsulating things into user controls and styles.
When using Blend, don't create layouts in the artboard, create them in the object outline. When I'm first developing a WPF UI, the hierarchy of objects is a hundred times more important than how it looks on the screen. I'm still learning to do this, and it seems possible that once I get good enough at it I won't need to prototype in Kaxaml anymore.
Work on the smallest thing possible. This requires a lot of discipline. I've got a nice big complex XAML file, and I decide that I need to edit the template of a control The first thing to do is to create a tiny XAML file with that control in it, and edit the control template there. The temptation to work like this in situ is strong, as editing the control template is only a right-click away. Don't do it.
Don't even think about whether or not I should develop a view model for my tiny little one-off application. Yes, I should.
Learn Blend. Really, really learn it. Learn what all of the tiny icons that surround the selected object mean, and pay attention to them. (Here's a shortcut: I didn't set margins on that thing, but Blend did. That's the answer to maybe 30% of my "what the hell is Blend doing now?" questions.) Use the Blend UI even if I know it would be faster to edit the XAML by hand. This is again a matter of discipline, resisting the temptation to get it done now so that I can improve my ability to get more of it done later.
That's kinda like saying "Sliced apples are easy to make, but apple pie tastes better. How can I make apple pie as easily as I can slice apples?" Well, you can make it easier by using pre-made pie crusts or buying pre-sliced apples, but it will never be quite as easy, because lets face it, you're making something that's a lot more complex and potentially tastier.
It sounds like making styles holds you up. You could get off to a much quicker start if you just imported the same styles with every project. Usually I fly right along once I have all of my styles made.
Otherwise, the only way to make it as easy as the drag-and-drop WinForms designer is to use the drag-and-drop WPF designer.
I've been using WPF for a couple of years now - for optimal speed, I disable the design-view, use snippets, intellisense intensively (and of course ReSharper).
And then I make things simple - I have descided to use standard layout for almost everything - ie. main-screen bit -> DockPanel, ToolBar docked top -> snippet.
Popup screen -> DockPanel, ToolBar docked top, custom Persistent section docked bottom (Save and Cancel buttons) - properties of the viewmodel -> UserControl with grid, labels and properties.
For styling - first do that when I have at least 3 screens for each type - create resource dictionaries for each type. Define common stylings - Header textblock etc. Import ResourceDictionary in each screen and apply styles.
Apply coloring, margins, padding etc. in App.Xaml with non-keyed styles.
I can't think of a faster way. At least for me, I don't really need to think while doing it this way (so, I can use my brainpower later for the complex stuff) - and it gives a consistent "LOB-look" that is relatively easy to style, theme and change later on. It's basically a matter of typing.
My biggest challenge at the moment is that I'm constantly thinking of ways that the UI could be composed dynamically with data templates, which can often get in the way of simpler solutions when the extra flexibility is not required. Other than that, I've become faster now that I'm getting used to the different containers and their quirks. It's such a dramatically different technology that it's going to take time before I develop the appropriate mental tool set for my day-to-day UI tasks, especially since I still need to use WinForms regularly. I figure it's just a matter of time, however, before I have standard patterns in mind that I can deploy quickly and easily.
The advice about VS2010 is very good; its visual designer is actually useful, compared to VS2008's XAML designer, which was less than useless.
Microsoft's PR machine pushes the "Model-View-ViewModel" pattern extensively for line-of-business apps, to the point where they actually recommend things that can waste your time.
Do not spend hours trying to shoe-horn everything into XAML, unless your company or client has procedures which require it. If you can code it faster in VB or C#, and the code is still maintainable, testable, and readable, do it.
Do not become an MVVM purist; not even Microsoft has figured out the appropriate balance for this pattern, and even with the Silverlight 4 stuff, they haven't come up with a good set of development tools or best practices for the pattern, even though it's now been almost five years since it was first proposed; there are still very valid reasons to abandon ICommand and INotifyPropertyChanged in favor of just calling a method on your ViewModel from the code-behind. Also, no non-Microsoft WPF/Silverlight expert I've listened to in the past few months has failed to say, "I'm not sure about MVVM yet, I'm not a purist."
Find a balance and use XAML for what works for you, and C# or VB for what works for you. MS devs on their blogs are fond of calling XAML "markup", and C# or VB is "code, unfortunately". Well, if you're typing it in or laying it out, it's all code, and the truth is that all that XAML gets interpreted and then turned into C# or VB in files you can't see or readily edit, before it's compiled down. (For example, Application.g.vb is generated from Application.xaml as a partial class.)
There are XAML constructs like animations and storyboards which take many lines to lay out in XAML, but in the procedural languages might only take one or two lines of code and actually be easier to read, especially if the animation responds to an event under only certain conditions. Do what works best.
Also, if you're coding along and keep hitting run-time exceptions which make no sense, take a step back, find an alternate answer that gets you functioning, and implement it. Most XAML errors can't be caught by Intellisense or the compiler. It's possible to bang your head for weeks against a XAML problem, that can be coded in C# or VB with early binding in a comparatively much shorter time.
In short, relax and code to your own best practices, using the VS2010 tools, and you should be able to pick up speed.
If you use VS2010 I think the visual designer for the XAML is better now and I think brings the development time more in line with classic winforms development.
If you still need to target .NET 3.5 you can by setting the solution to compile to 3.5 instead of 4.0. This might be a good option for you if you aren't using VS2010 yet.
I feel your pain... Everytime we add a new field into the database, another TextBox/ComboBox has to be made on the form. I've found that using Expression Blend allows me to be much quicker at laying out the form. The downside is that using Blend tends to create more xaml than writing it by hand, so I usually end up cleaning up the xaml a bit.
In the end, Blend is a much better designer than Visual Studio (2010 included), so it's much quicker to do your design work in Blend, and development work in VS. (just my two cents)
Well we are considering to move from WinForms to WPF, what pitfalls does WPF have? And we got component one's flexgrid is there any wpf grid that has the same functions? one nice thing with it is that you can implement your own draw method for the cells... It can merge cells print and save to many file formats..
In general, WPF development is very different from WinForms. You should expect it will take some time to learn the new technology (or you might even need to hire new developers =)).
WPF approach is in many ways better than WinForms' one: check out styles and triggers, data binding, control templating, eventing model.
I would recommend you to start exploring it, but wait for the WPF 4 (and the boring MSDN page) to start the actual migration, because it is going to be even better and close some of the very annoying gaps.
First of all, WPF works pretty different from Windows Forms and likely requires a different approach on how to structure and design the application. At least it works way better if you do it the way it was conceived.
As for single Windows Forms controls, this shouldn't be a problem. There is a WindowsFormsHost which enables you to include Windows Forms controls in WPF.
The change from winforms to WPF is not a change I'd reccommend unless you have specific requirements which WPF fulfills - WPF is not intended to be a replacement, simply an alternative which is more suited towards graphically rich applications.
If you do have a specific requirement then you also might want to consider embedding WPF controls into winforms applications, rather than converting your entire application.
The learning curve is slow to get going, but once you get the idea it all starts to make sense. We have "Pro WPF in C# 2008" book floating round the office and its been a great help. Of course most things get googled to find an answer, but to find out why something is done the way it is this book was a great hope - to me anyway.
There are some annoying features but its still WPF is still quite new. Like most things, if you come across a problem someone has likely come across it before and there is an answer out there!!
J
Take a look here for a datagrid: http://wpf.codeplex.com/Release/ProjectReleases.aspx?ReleaseId=29117
The main hurdle with WPF is simply the huge amount of new stuff to learn (if you wish to use it properly). I'd think twice if you're on a tight schedule, but it might be worth it if you have 6 months to spare...
Speaking from just my experience, moving from Windows Forms to WPF took some re-learning. A few months into the transition most changes made total sense. WPF removes much of the frustration associated with using Windows Forms. It allows for a truly rich UI development experience especially when working in tandem with designers. I strongly recommend WPF Illustrated by Daniel Solis as a learning aid.
With reference to the grid, Syncfusion offers a WPF grid control that implements the features you have asked for. It implements true virtual mode with cell level customization, printing and export to multiple formats including Excel. Disclaimer - I work for Syncfusion.
i've been learning wpf for about a week now..
and i have a basic question:
From a business view and development view (out of your experience).. what can and what cant be done with wpf(capabilities) ..
please try to be illustrative..
examples of undesired answers:
"Fully functioning stand alone applications with alot of animation and Glittering images"
A second question:
if i build a XBAP UI for my application, can i make the UI "not show" in a browser!
if u r going to answer from tutorials/websites/books.. please dont copy paste them directly, try to write it in your own words...
You can host anything built to the Win32 GDI/USER API (WinForms, ActiveX controls) inside a WPF application, so even if you hit some limitation with an app that is mostly WPF, you can always host some old controls inside it.
And since 3.5 SP1 you can even host animated DirectX graphics pretty seamlessly as well (although WPF's 3D support provides its own much simpler ways of achieving the most commonly done things).
As for comparison, the major advantage of WPF over WinForms is the way it keeps closely to its own component-based model, so a very large proportion of controls are able to act as containers for other controls. Want to put a combo box in a menu item? Not sure why you would, but you can. More usefully, you can put a button in a list box (or tree view). These kinds of thing are not possible unless you implement every standard control from the ground up (which is what WPF does).
The disadvantages are probably temporary: it can be a little unstable on some machines (the rendering code seems vunerable to display driver incompatibility) but this gets better with each service pack. Also the text rendering has been heavily criticised - it goes a bit further with ClearType anti-aliasing than Windows normally does, so some people complain that it looks blurry.
(The reason these are likely to be temporary issues is that Microsoft's Visual Studio 2010 is adopting WPF. So they are now "eating their own dogfood".)
You can pretty much do anything in WPF that you'd need from a GUI app. But that's not the real benefit, IMHO.
One of the real benefits of WPF is development speed and simplicity, once you get past the learning curve (and there is a learning curve!)
The other major benefit, and probably the biggest one, is that it allows designers to work on the presentation, do lots of interactive things, all using a designer-friendly (friendlier, anyway) tool and not having to submit requests to the coders. Just by changing the .xaml, a designer can make an application look almost completely different, and add all kinds of behaviors (panels disappearing, expanding, all kinds of neat stuff). Without changing a line of code.
You can in theory do anything in WPF what you want. Compare it with a WinForms application. Is there anything that you can't build with that? Not really. The same goes for WPF. It's just that WPF is better suited for some things, like animations, video, graphics, etcetera. As it is xaml based, it is also better suited for databinding against XML for example.
See also this related question.
As for your second question, I'm not sure what you mean by that. Do you mean if you can show websites using WPF? Yes of course, just like WinForms.
Oh, in WPF some things are still not implemented. DataGridViews as popular example are only in the codeplex preview. YOu have alot of things like theExpander which work in a differnet way, and you can have a lot of problems with autosized content.
Do you expect your WPF developers to know expression blend?
Any good resources for learning more about Blend?
[UPDATE] Does knowing blend make you more productive?
I found Blend a great way to ease into XAML. Many of the common things you want to do are easy in Blend, especially databinding. Databinding has no intellisense and I found doing things in Blend a great way of discovering how do write the databinding syntax.
I now find myself mostly editing raw XAML buy hand.
The areas where blend is really handy:
Customizing templates.
Animation
Breaking the UI down into user controls
As a WPF developer I surely see the benifit of knowing Expression Blend for many of my previous projects. This help me to jump start on creating Usercontrols and Custom controls very effectively. And if we do in the conventional way of writing XAML from the scratch, it is gonna take a very long time of your development.
And also for creating DataTemplate,ControlTemplate,Styles and ItemsPanelTemplate - it is just a click away in Expression blend.
So I highly recommend Expression blend for a WPF programmer
I typically work in both blend and Visual Studio (2005) side by side when doing WPF development. (Although, granted, I typically do both design and c# coding).
The benefits of using Blend is that certain tasks are extremely fast there - things like picking colors/brushes, creating animations and layout fixes such as tweaking margins/paddings.
Another usage is to instantly see how your hand written XAML will look like without actually starting the app.
Blend has a bad habit of producing some weird XAML so I always have to clean it up in the VS text editor afterwards. I still find it to be a net win to use blend though.
So, to answer your question: Is Blend required? no, not really. But it will make your life easier for certain tasks and thus make you more productive.
Things like animation and gradient color definitions can really only be done effectively in Blend. Blend is also often extremely useful for generating some non-trivial custom visual elements, just so that you can view the generated Xaml and import a CLEANER version into your production code. Unfortunately, the point-and-click nature of Blend disguises the fact that huge volumes of very messy Xaml is being generated under the hood, and you'll want to REFACTOR that Xaml before using it in your production source. Fortunately, learning Blend is not that hard. The best tutorial I ever found was called the "Fabrikam" tutorial. There may be updated versions available, but one version of that tutorial is still available at the link below.
http://blogs.msdn.com/expression/articles/516589.aspx
Realistically, very few dev. shops have access to qualified "interactive designers" (its not somethiing a company can just re-task one of its junior Mar-Com people to perform), which means, at most places, developers will need to learn some amount of Blend if marketing wants to add the kind of fancy visuals that provide alot of the justification for using WPF in the first place.
As a developer, after working intensively with WPF for several months, you will find yourself becoming totally comfortable editing Xaml directly and, unlike with Windows Forms, you'll rarely rely on features in the VStudio designer. Not only is direct editing MUCH faster than scrolling through property lists, but VStudio does not have point-and-click support for many of the features you will use in production WPF applications (they just got around to adding an "event" tab in SP#1). Blend has more support for many of these items (it can generate a DataTemplate, for instance), but I usually only jump into Blend to create a quick animation or other visual effect, cut and paste a carefully-refactored version of the markup into my "official" VStudio project source, and move on.
I think at least the designers should start using the Expression Suite.
The developers should be somewhat familiar with the tools but just enough to enable them to communicate better with the designers.
Since there are not so many good WPF tools, knowing Blend is a pretty useful skill. However I wouldn't consider it as requirement. The whole idea of WPF is to distribute work between coders and designers. IMO developer is not required to know Blend throughout, but basic skills are required to understand designer's needs.
Video training for expression blend:
Total Training Expression Blend
http://expression.microsoft.com/en-us/cc136536.aspx
http://windowsclient.net/learn/videos_wpf.aspx
I (as a developer, not designer, soo not designer) tried to start learning WPF through Blend. While I could get stuff working, looking back at what I produced makes me shiver.
Now that I know my way around WPF pretty good, I still use Blend and Design every now and then, but my work is based in XAML (not designer view in VS, mind you, but XAML). In other words,
I know how to clean it up now.
I'm still wondering how I can get my Adobe-Flash, -Photoshop, -Illustrator design guru to work with me in WPF.
It fully depends on what you want to do. To answer your second question, would you really want to try editing an animation storyboard outside of Blend? If you're working with the actual Visuals of the application, Blend is best suited for this. If you want to hack around with databinding, validation and other things where you must swap back and forth with code. Obviously its more sense to work on the XAML in Visual Studio.
Lynda.com has some cool expression blend training available online...
Getting Started with Expression Blend by Lee Brimelow
Developers don't need to know Expression at all.
What you do need to know is XAML and not hide behind some tool, which would be the worst thing you could do as a WPF developer. Your tool of choice is yours to decide on. I used to use the XML editor in Visual Studio.
The only persons who need to know Blend are the ones in charge of the visual aspect of your WPF application. They have to be able to understand how to skin your application with templates, but other than that, they can keep to Blend exclusively.
In general, I think it's more important to for developers to understand XAML, as Blend is just a view on top of it. XAMLPad may be more useful for learning XAML in the first instance.
More specifically to this question though, I think if developers are working alongside designers using Blend, it could be very useful to know at least the basics. As well as allowing better communication (as mentioned by #kokos), it will let the developer perform minor edits (such as alignment etc.) in the same environment, and also understand the limitations and boundaries of the tool with respect to the code generation.
Historically, designer tools have had a few quirks that developers have had to work around, such as re-coding HTML in FrontPage, or generating font tags instead of using styles or classes. I'm sure Blend wouldn't do such things, but it might generate XAML that the developer would prefer to restructure or slim down, so knowing which features generate which styles of code could be very hand for the developer.
Would you require your HTML developers to use DreamWeaver?
All good WPF coders should know XAML by hand and only use tools like Blend for quick mockups, for doing animations or tweening, or for doing complicated gradients, etc.
Coding XAML by hand is a requirement for good WPF developers - Blend is a tool, not a substitute for knowing XAML.
Brennon Williams new book should also be good!!!
(source: pearsoned-ema.com)