I also have a desktop application written in Windows Forms that is a middling size (a couple dozen major forms backed by 46 tables in the database). I'm thinking about rewriting the UI in WPF, but before I go there I was curious if there were any war stories about doing such a conversion.
I use LLBLGen to generate my low level data access objects, and I have a business logic layer above that. The forms are databound to the business logic objects, although the main form uses caching objects to minimize round trips on the more common navigation routes. The UI never speaks directly to the database: always through the UI -> business logic -> low level -> datastore path.
One control that I use heavily is the TreeView, which acts as a visual guide and short range navigation tool. The tree has been heavily customized with icons, highlight colors and it is the control I worry most about porting.
Is there a story that might convince me to go ahead and convert (or conversely, wait until Microsoft is closer to pulling the rug out from under Windows Forms)?
EDIT: I was asked in a comment what motivation for conversion I have. I have some concern about future proofing: I have 500,000 lines of code that were originally ASP and VBScript. We have been porting the functionality over time to ASP.NET and C#, but only as we make changes to the code. The upside is we have kept costs minimized, the downside is half the code remains ASP and VBScript. I'm concerned about a similar situation arising with Windows Forms applications.
Am I worried today about Windows Forms going away? Not even close to it... but the application is moving from ASP and VBScript to ASP.NET and C#, has nine years of history behind it, and probably won't be replaced this decade (instead, simply it will evolve). The desktop application is likewise a long term project with years of history.
For me, the WinForms vs. WPF decision is a simple one - if normal people are going to use it, the user interface can make the difference between a winner and a loser.
It is definitely a steep learning curve. But I have NEVER gotten done with a nice looking WPF application and said "Man, I should have used WinForms".
I'd say invest in the effort to make your UI better whenever possible for your customers, so yes to WPF if that's the case.
WPF has a ridiculously large learning curve. It will most likely require you to rewrite a lot more than you think for just changing the UI. Also, a lot of features that would make WPF nicer to use just aren't implemented or included in WPF yet. Unlike routeNpingme, I have written nice looking WPF applications and have said, "What a waste of time, I should have used Windows Forms and completed in 70% less time".
EDIT:
Also, unless Microsoft figures out a way to make WPF easier to learn, I don't see it catching on to the masses at all. WPF can do some very cool things, but a little effort to make it easy to understand instead of throwing stuff over the wall would have gone a long way. It would not surprise me in the slightest to see Microsoft drop WPF for something easier to work with in the not too distant future. So don't go changing your Windows Forms application just for the sake of changing it.
Pros:
Ridiculously easy data-binding (most of the time)
Ridiculously easy customization of look and feel
Cons:
Very steep learning curve
Some obvious bugs or issues. Similar to .NET 1.0 Windows Forms
Little or no tool support
In my opinion, WPF will definitely replace Windows Forms at some point. However, right now the tools are the main thing keeping it back. I disagree with Dunk that Microsoft will drop it for something else. Change it yes, but I think it's here to stay.
Should you change your application to use WPF now? No. Feel free to learn WPF but if your application works fine currently, then WPF won't give you anything extra. It just makes doing what is possible in Windows Forms much easier.
WPF is great. It is particularly good for extending controls like TreeView with customisations. You can add a string as an item in a TreeControl. You can also add a small panel containing an image and some text in various fonts and colours. Or you can add buttons, or anything you like. It has a completely general composability system. Same goes for ListBox, ComboBox, Button, etc. All their content or child items can be as simple as a string or as complex as a multipage document viewer with zoom buttons (if you want).
But the only way to find out is to try porting one of your forms. It shouldn't be too hard to make a WPF Window open from within your existing app. I started using WPF by making new GUI panels that were hosted inside a C++ Win32 application. Eventually it was so obvious that WPF was the way to go that we switched it around and made the outer shell WPF, with some ancient dialog boxes still implemented by the old C++ code where we couldn't be bothered to rewrite them (probably exactly what will happen with Visual Studio 2010).
Porting is a tough decision. So just some thoughts to help you decide.
WinForms is OK while you work by the rules and keep everything drawn as is. But even redrawing a border on some controls may require complex and precise work and skill, as you already know from tree customization. The same tasks can be done in a very elegant way in WPF.
Also, the data-binding in WPF saves me a lot of time. In the long term, you end up thinking about data-binding scenarios that could not be remotely possible in WinForms without special-case coding.
I do not even consider WinForms for new development -- there is no excuse for customization costs.
I have started introducing WPF elements within my WinForms application and so far have had a lot of success.
The application's main component is a grid control and I haven't yet found the text rendering of WPF sharp enough to present a table of important textual data.
But the application has several additional panels, and the majority of these are implemented using WPF. So, I'm going for a hybrid of WinForms and WPF via the ElementHost control.
I have found the flexibility of WPF to allow for a much more attractive and usable UI, and my users seem very happy with it. In my case, it's also been politically easier to introduce WPF one panel at a time.
WPF's main value to me is in the binding, not in the cooler UI. The worst WPF I've ever seen is when people use WPF just because it's newer, and put all the work in the code-behind, including not using binding. What you get is WinForms data management. So be sure you're going to use the wonderful binding when you do WPF.
I would port the OP's business logic to a business layer for ease of maintenance and conversion. I wouldn't port the WinForms to Xaml at all unless new Xaml functionality was needed, and preferably not until after the functionality was ported.
Related
When I first learned about Microsoft's then-new framework for developing desktop applications, WPF, I thought that one of the biggest benefits of it would be its efficiency. After all, I already know what the GUI controls and elements were that I wanted to use--I just have to slap them all on the page and then wire up all my bindings right, and I'll be done. After that, I learned about the MVVM pattern, which promised clean separation of concern within my WPF app.
I thought this was going to be great! I got into creating several different admin and data entry WPF apps with my team at work, and thus I began to crank out working software with robust but simple GUIs, right?
Not so fast, there, cowboy coder. My experience is that writing WPF is S-L-O-W.
Well, at least the way I do it. You see, after I have a picture of my GUI on a whiteboard, I code up the XAML with the controls that I want. This part, as expected, is fast--laying out the whole of a window is pretty quick. After that, its all the little stuff you want these elements to do takes awhile. I always seem to want to make this text bold in some cases; show a red error box in these other cases.
Then things unravel: this binding isn't working right over here--I have to write a converter and adjust the layout for the right values. Whoops, I forgot that extra NotifyPropertyChanged there. Oh, and I want to use a different template in this state vs. that, so I have to figure out what I can use to swap the templates in certain situation. This data is coming in asynchronously, so I need to make sure the right thing is happening on the right thread and that Property gets NotifyChanged as well. Crap, when I maximize my window, it doesn't stretch like I thought it would--must be because its container height isn't defined, but I don't want to define that, so I have to make it stretch in its parent. Oh, now I really want to make a user control out of this stuff over here, so I better implement some dependency properties...
On and on I go, spending hours and days on stuff that just feels so small and minor. I soon resort to cutting usability features and look-and-feel enhancements because this is taking just too darn long.
Does anyone have any tips or principles I need to try in order to write WPF efficiently?
A couple of things that have saved a lot of time for me:
Use DockPanel as your default panel for layout unless you have a good reason not to.
Keep a folder full of useful classes: a ViewModelBase class that implements INotifyPropertyChanged, a RelayCommand class, etc. There's no need to get fancy and try to make this a separate assembly that you build into your project; just write reasonably good implementations and copy/paste them into your new projects.
Get Resharper and use it. Use templates for creating dependency properties, properties that do change notification, and commands.
Find or build a good library for asynchronous task management.
I find that even for very simple applications I get more done faster with WPF than I did with Windows Forms. For applications that aren't very simple, there's absolutely no comparison.
For the most part, WPF applications are a lot of work to develop because it's harder to make the case for cutting out UI features. You can't just say, "Oh, that's not possible," because it probably is possible (whatever "it" is).
Write your own library, or find an existing one.
WPF is great, but out of the box it is missing some things that would make coding faster. I got tired of writing the same things repeatedly, so I ended up creating my own library full of things like converters, visual tree helpers, attached properties, custom controls, etc., and since then, my development time has sped up considerably.
In addition to my own library, I've also started using Microsoft's Prism and Galasoft's MVVM Light Toolkit. Both contain useful objects that I use all the time and are better than what I could code on my own. (Most used are NotificationObject from Prism, RelayCommand from MVVM Light Toolkit, and EventAggregator or Messenger from either one depending on the project, etc.)
Another thing I've done to speed up coding time is to take advantage of Visual Studio's macros. For example, to create a property with Change notification, I write the private property, hit Ctrl+E, Ctrl+R which generates the public version, then run a macro which automatically sets up the PropertyChanged notification in the setter method.
I almost never change the setter methods from the default macro'd one, and instead use the PropertyChanged event to handle any changes that should occur on the setter. This not only makes it easier to track application flow, but also greatly reduces the time I used to waste browsing through my public properties to alter a setter method.
I believe the right answer isn't for WPF at all, but it can fit what you're looking for.
Most of the times, when you want to leverage a new technology there's a time while you're not efficient, productive and your solutions aren't that impressive, innovative or just doesn't look like others.
What will give you more efficiency is working with WPF itself.
It's more about project management topics than programming. After finishing some project, your team and you should go to some room and discuss:
Success stories.
Problems during development.
Pros and cons.
Fails in the application architecture.
Communication problems within the team and customer.
... and so on.
If everyone shares their knowledge, project manager or team leader does a good job documenting each project story, finally everyone will have a "know-how".
In addition, it's important that you won't need to reinvent the wheel for every new project: if some pattern worked fine, do the same way next time, even if it's not the best way of doing it. And try to enhance it, if possible.
Design patterns, technologies, paradigms, languages, companies, colleagues and nothing are a silver bullet: Microsoft said WPF is a step-forward in Windows client developments, and it is that: a more modern approach to provide shinny user interfaces and a programming paradigm that fits nowadays' desired approaches, easing the relation between coders and designers, as WPF has XAML, which allows not only separation of concerns, but separation of professionals by area (designers, UI programmers, business programmers, ...).
Finally, as I said above, WPF won't be your silver bullet: learn from your own success and read a lot, see sample applications, download open source solutions, listen your colleagues, drink a coffee and, after all, after some headaches, some day in the near future, you'll leverage these technologies (and many others).
EDIT
I'd like to add that a good way of using the know-how is creating a Visual Studio guidance pack, so you can automate a lot of tasks like creating managers, views, models and other things just in the way your team would do by hand.
For example, you can create a guidance pack for a WPF CRM-like application and you can automate module creation. When you want to add a new module, guidance pack starts a process which adds all the necessary classes to start development this new module, and it can create a sample form already associated with a navigation manager, controller or whatever (it's just an example).
Guidance pack and T4 would be both good tools for automating tedious or repetitive tasks in everyday's tasks:
http://msdn.microsoft.com/en-us/library/ff631854.aspx
http://msdn.microsoft.com/en-us/library/bb126445.aspx
I have been using WPF since 2008 and can honestly say to do it right and clean does take more time than the same thing in WinForms would take to develop. I have written a lot more WPF than Winforms. That being said - if I need a simple internal utility - it is ALWAYS Winforms. If I have something forward facing to a client - it is always WPF. Why? Winforms are cheap and dirty and you get a lot for free. What you don't get is the fit and polish that WPF can provide. The flexibility with WPF does come at a cost - but in the longer run it's worth it for public facing software.
Yes WPF is a hurdle but it also has rewards. You are on the right track with a design pattern such as MVVM. Sounds like you have not even gotten to the "rewards" of dependency properties or event bubbling. But the control over the UI is great. Almost everything is a content control. In forms I was always writing custom controls to get the UI I wanted. In WFP I have never had to write a custom control for UI and doubt I ever will. The syntax is new but it is compact - I rewrote a Form app in WPF and the WPF has 1/3 the lines and more features. Read a whole book on WPF just to get grounded - I like PRO WPF in C# 2010. You could also say LINQ is complex but man does it do a lot in just a few key strokes. WPF is not something you just pick up on the fly as you next application.
I've spent some time working on WinForm user and custom controls. However, in the back of my mind are the increasingly loud voices saying that WinForm technology is obsolete, and that WPF is the future on the desktop.
I've only looked superficially at WPF. Can anyone comment about if WinForm user controls can be used at all on WPF, and how different WinForm user controls are from WPF user controls?
Most of the controls I'm working on do some type of owner-draw as opposed to child controls being dropped onto the control. I'm just wondering how much of this code will be reusable under WPF.
It is certainly possible to use WinForms controls in a WPF application using the WindowsFormHost control. As usual, there are a few caveats. In particular, the two control types don't overlap well.
However, doing so seems that it would prevent you from taking advantage of many (if not nearly all) of the benefits of switching to WPF in the first place. If you have a large code base that's working for you, I'm not sure why you feel you need to migrate. There will always be something newer that comes along. The real battle is figuring out whether it's really better, at least for your particular situation.
Mandatory disclaimer: I'm far from an expert on WPF and apparently quite a bit less jaded on WinForms than many developers are. So perhaps my advice should be taken with a grain of salt, but I think it's worth considering nevertheless.
Your controls will be reusable (through WindowsFormHost, as Cody suggested). However, I'd not bank on being able to port your code across to WPF. The fundamental programming model is quite different (WPF relies heavily on data binding and thus benefits from very different code-behind), as is the rendering model (WPF doesn't use GDI+). The best way to approach most controls in WPF is to use the built-in templating; other than custom layout panels (which isn't really "drawing"), I've found nothing so far that requires custom draw methods in controls.
It'd certainly be a waste to create a WPF application just to host your WinForms controls. WPF may (or may not!) be "the future" but that doesn't mean you should throw away what you've got on a whim.
You say you've only looked superficially. If you think it might be worth investment, why not do an R&D project to prove how the integration might work on a small part of the system?
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.