I am programming simple Windows apps. I don't need DB support. Why would I use WPF instead of WinForms?
One obvious answer is that WPF offers a richer user experience than WinForms, allowing for animations (even 3D) in the user interface, for example.
From a development perspective, it goes a long way to enforce the separation of the User Interface (in the XAML) from the business logic (in VB.NET or C#), which is always a good thing.
A Google search for "WPF vs WinForms" brings up lots of pages that discuss this issue. I won't repeat all their findings here, but this page raises some interesting points:
Databinding in WPF is superior to what Windows Forms offers.
UI and C# business logic can be cleanly separated in WPF
Storyboard
Data/control templates – a much cleaner way than anything Windows
Forms can offer.
Styles – cool and simple. Its so easy to style all your buttons in an
application to have the same look and
feel.
Even if the VS designer breaks, its easy to code XAML.
UI virtualization – I’ve got grids with 100K rows, ticking off a moving
market. Performance would be dreadful
if it wasn’t for UI visualization
which come for free.
3D support.
Nothing scientific but, UI development feels quicker in WPF –
maybe its just because a WPF
application looks cooler at the end of
an iteration, or maybe its because
development really is quicker.
I can add a User Experience engineer to my team, and with no C#
knowledge he can work magic in
Expression Blend and give the
front-office trading application a
makeover that is guaranteed to win
over the business users.
WPF is the current platform for developing Windows desktop applications. It is a modern, advanced, hardware accelerated framework for developing applications that maintain separation of concerns. It supports advanced rendering of 2D vector and 3D graphics, providing an immense range of capabilities for building rich, interactive, and quality user interfaces.
WinForms, on the other hand, provides a basic platform for developing "classic" Windows apps with your standard look and feel using standard controls. It does not offer the rich, hardware accelerated, vector 2D and 3D capabilities that WPF offers. WinForms applications tend to have much greater coupling between application behavior and UI (view), which presents a less flexible platform upon which to develop applications.
As for which one you choose, it entirely depends on your needs. If you need vector graphics, 3D rendering, the ability to create rich, interactive, animated, modern user interfaces, and/or wish to maintain separation of concerns, WPF is definitely the right choice. If you need none of that, and just need to create a simple UI that solves a simple problem, WinForms will meet your needs just fine.
To learn.
To have greater (i.e. any) control over the appearance of your program
To benefit from easier data binding, triggers, styles
(I don't see what DB support has got to do with it)
WPF can utilize hardware acceleration to some degree, but that is expected to improve over time.
Also, because of XAML, you have more options for "doing stuff", declarative vs. programmatic, or a mixture of both.
Microsoft no longer does active development on WinForms, they are strongly pushing WPF, and for good reason.
WPF allows for much easier "resolution agnostic" designing. To achieve that in WinForms, it is a lot more work.
The MVVM pattern was already mentioned in one of the comments, this allows one to do real unit testing vs. GUI-based testing on your code, that is a big win, in my experience.
Nobody mentioned about better testing capabilities of the WPF applications (if they are written in the correct way, for example based on the MVVM pattern).
A
Anywhere Execution due to XAML.
Can be used as WinApp, WebApp, Mobile.
Whereas WindowsForm Internal UI representation is in C#.
B
Binding -->Simple object to object data transfer.
C
Common look and feel(Styles) -->can define look and feel styles commonly and use it for bunch of controls.
D
Directive Programming -->Binding objects in XAML.
E
Expression blend and Animation-->WPF uses DirectX, and DirectX can be used for animation.
F
Faster Execution(Hardware Rendering)
WPF internally uses DirectX (Hardware rendering) while Winform internally uses GDI (mostly uses Software rendering).
There are two ways by which a computer renders display on monitor.
1) (CPU) Software rendering -->In case of CPU rendering ,the CPU drives the whole logic of rendering display on monitor.CPU also does other operations like running applications,performing memory management,running OS. So on top of it its extra load to display things on monitor.
2)(GPU) Hardware rendering -->Its Specialized kinda processor, specifically meant for rendering and display faster on monitor.
Now in WPF, this rendering is further optimised in
>Tier 0 mode (Software rendering) uses DirectX7 internally,
>Tier 1 mode (Partial Hardware rendering) uses DirectX7 to DirectX9 internally,
>Tier 2 mode (Hardware rendering) uses DirectX9 internally.
G
Graphic Independence (DIP) -->Means resolution independence
Resolution --> Total number of pixels that fits into screen/monitor
Pixel --> Simple dot on screen.
Windows form uses pixels as a measurement unit, so when pixel changes then win forms has to adjust itself that means we have to write logic for it.
But WPF does not use pixels as a measurement unit but uses DIP(Device independent pixels)
1 DIP = 1/96th of the inch.
At last Testing --> Better unit testing with use of MVVM pattern.
If you want to have a rich user interface like the image posted in your previous question, I'd recommend going with WPF. Aside from making it easier to create a nice-looking application, it's also the technology Microsoft will push in the future. There's almost no new development for Winforms.
The single most important difference between WinForms and WPF is the fact that while WinForms is simply a layer on top of the standard Windows controls (e.g. a TextBox), WPF is built from scratch and doesn't rely on standard Windows controls in almost all situations.
A great example of this is a button with an image and text on it. This is not a standard Windows control, so WinForms doesn't offer you this possibility out of the box. Instead, you will have to draw the image yourself, implement your own button that supports images or use a 3rd party control. With WPF, a button can contain anything because it's essentially a border with content and various states (e.g. untouched, hovered, pressed).
check this article it will help you:
https://www.wpf-tutorial.com/about-wpf/wpf-vs-winforms/#:~:text=The%20single%20most%20important%20difference,controls%20in%20almost%20all%20situations.
Related
Actually, I have started learning WPF. I have few months of experience in developing Windows Forms applications. Though, I am getting the meaning of a WPF application, but still I am not able to differentiate the difference between two, on the basis of their output.
With reference to this Link: Device Independent Pixel (DPI), I have learnt that whenever the operating system render a WPF application it manages its size itself according to its resolution.
So to check this difference, I created two demo applications in both frameworks and changed the resolutions as well.. but I didn't find any satisfactory difference. Which could explain it is a WPF application and this one is a Windows Forms application.
It does not create any scroll bar on maximizing and doesn't make the button big or small on changing the resolution.
I have read somewhere that Visual Studio 2010 has been rewritten in WPF. But in my experimentation I saw that, (on changing the resolution of desktop) it makes text and graphics unreadable/blurry. On re-sizing its window, everything was getting hidden except the menu-bar. And the menu-bar content was shifting its positioning, e.g. far right one menu items were shifting down. Why?
Kindly make me correct & explain a little more bit (this display issue) too.
To answer this question properly I should write a whole chapter, but I keep it short:
There are three major differences between a WPF application and a Windows Forms application: Layout, Render, Presentation
Layout:
WPF layout system provides a greater flexibility in arranging the elements on the fly. It is based on the Element Bounding Box (as opposed to precise pixels in WinForms) and Measure and Arrange mechanics (as opposed to UpdateLayout in WinForms) that automatically and dynamically finds the place for each element without any need for a manual update.
Basically, all elements bounding box are measured first and then are arranged using multiple methods such as Measure, MeasureCore, ArrangeCore, MeasureOverride, etc.
Unlike WinForms, where you have a pixel-perfect size for everything, in WPF you have much more options and complexity such as Width, ActualWidth and DesiredSize (and even Transforms as LayoutTransform) for the same element.
This is why
As you type in a WPF TextBox, its width might increase and push other elements away or even push some elements into a new row (like the menu bar you've observed)
As the size of a control changes, it affects the available space for other elements. So their size and location might change accordingly.
When the window is being re-sized or resolution is changed, it immediately updates the layout and changes the size of elements in order to fill or fit the space. Here you'll find out more about Layouts.
using Margin alone (without using layout capabilities) to arrange elements is not the best idea in WPF. As it's the WinForms mindset which isn't much helpful while developing WPF.
Render:
WPF uses double data type for Layout (as opposed to pixel-perfect WinForms) and therefore you might see the edges blurry sometimes, but it can be avoided with SnapToDevicePixels=true.
WPF is much more efficient in utilizing the GPU to render a GUI. Try a grid of 30x30 TextBoxes in a Windows Forms application and a WPF application. No matter how messy you write the WPF, it never blinks and it still runs much faster than Windows Forms. Even adding a handful of animations, visual effects and styles on them does not hurt your performance like in Windows Forms.
Remark: To avoid a speed decrease and blinking in a Windows Forms application, you should set DoubleBuffer of the form to "true".
You can use any Transform as RenderTransform to easily implement smooth zoom/rotate, or develop custom GPU-based shader effects, and much more in WPF. (I think everyone agrees that doing such things in WinForms is feasible but real pain and you most likely will give up and move to GDI+ or DX if not out of frustration then because of the bad performance.)
And the last and the most important:
Focus on presentation:
When develping WPF Applications you have to stop thinking in Windows Forms: No more UI events, accessing controls by their names and writing logic in code-behind and start to think in WPF: Binding, Commands, Resources, Styles, Templates, Converters, DependencyProperties and their callbacks.
The real power of WPF lies in separation of 'View' and 'Logic', Which can be achieved using the MVVM pattern.
It makes the most visually-complicated problems quite simple and easy to develop and easy to write Unit Tests for.
Once you got the hang of it, you will realize there's no limit in how you can present the data or show off an awesome GUI looks.
If you've planned to switch to WPF, you've made the right decision. Always stick to MVVM and AVOID CODE-BEHIND AT ALL COSTS! (i.e. unless you are doing a pure UI operation: do not write code in .xaml.cs files, do not access x:Name in cs files and avoid UI events.)
Windows Forms (WinForms) and Windows Presentation Foundation (WPF) are two different ways of building the user interface for your application. Windows Forms is the older technology and its controls are found in the System.Windows.Forms namespace. WPF is a newer technology and its controls are found in the System.Windows.Controls namespace.
WPF
Pros:
Powerful styling and skinning structure
Easy to create your own look and feel
Does support Windows Forms
The future technology for developing Windows Vista applications
The ability to reuse existing code
Highly advanced data binding possible
Cons:
Declarative vs. procedural code
Requires .NET Framework 3.0
Compared to Windows Forms, still in development phase
Requires Dx9 compatible video card for advanced graphics
Windows Forms
Pros:
Extensive documentation to be found on the Internet
Plenty of examples
Does support WPF
Cons:
How long will this be supported? (I've read somewhere that Microsoft is just developing WPF now, only maintenance for Windows Forms).
Design your own look and feel in an application is a lot of work.
As far as I know WPF applications should work faster than Windows Forms applications because WPF applications use DirectX for rendering instead of GDI. But what kind of application will start faster: WPF or Windows Forms? Will the start time be roughly the same or will one type of application be considerably faster than the other?
I am not targeting any specific operating system.
Just to point out, in my experience the WPF renderer is in fact quite a bit slower than Windows Forms, despite using DirectX. This is because lots of tesselation and layout calculations are done on the CPU side, which effectively cancels out the performance gain of using the GPU.
Just google around for "WPF Slow" or "WPF Performance" and you'll find horrified developers shocked to learn their time and effort spent converting WinForms to WPF because of spin about GPUs has been wasted, as the result is slower than the original application.
However ... I will say this. WPF is far superior to WindowsForms in terms of styling, graphical capabilities, developer productivity (databinding), animation, look and feel etc. If performance really is an issue, on certain areas you can optimise. For instance, did you know that you can get an API to write directly to bitmap in WPF (see the WriteableBitmap class) to do GDI-like operations in memory? This is (surprisingly) about 20x faster than the WPF primitives for some operations.
Similarly you can use virtualization to improve the performance of datagrids etc. Telerik have an example of their grid scrolling 1,000,000 rows at interactive framerates.
In conclusion, have a think about what you are doing and see similar examples on the web. Are you doing real-time scientific dataacquisition and visualization or just a standard line of business app? Comparing similar examples to see what the framework is capable of will help you in your decision.
Update 2013 Q3
As an update, in various projects I'm now seeing faster and faster performance from WPF by moving anything and everything off the UI thread. E.g. leave the UI thread just for UI, do as much work as possible using Task Parallel Library or RX. Make everything async and don't block the UI thread while waiting.
Eliminate binding errors as these contribute to WPF performance problems.
You can move animations (e.g. wait or loading animations) onto a different thread for glitch-free animation. You can use render-to-bitmap when doing animated transitions.
The long story short? It is possible to get great performance from WPF applications (as well as slick UI) but you need to put in a bit more work!
I think the start time will be about the same.. I have created a few WPF applications recently and in some cases I think the initial loadtime is a bit slower than win forms, but it is not much and WPF more than makes up for it when the application is up and running
From my experience, I think WPF is quite reactive at start compared to winforms. However, the question is tough, especially considering that WPF can contain the other and vice versa.
I'd follow the philosophy of this article : http://joshsmithonwpf.wordpress.com/2007/09/05/wpf-vs-windows-forms/
WPF and Winforms are just not the same tool, and neither of them is supposed to substitute for the other ;)
The question has a lot of duplicates on this forum, please check here for a link and discussion and all of them : WPF vs. Windows Forms
I am very confused about WPF and Windows Forms. What is the usage of WPF over Windows Forms?
What is the usage of WPF?
WPF is a new platform for developing applications for Windows (and for browsers). WPF is not necessarily there to replace Windows Forms. With WPF, it is easier to add 3D, video, and animations to your application. Because it is XAML based, it is also easy to bind to XML data, for example, data from a webservice, and dynamically load it as content.
WPF also, in my opinion, better seperates the UI programming from the business logic. It is easier to have an advanced WPF designer build your UI with a tool like Expression Blend, and yourself as a programmer, focus more on the back-end. In that way, it is more like having an HTML and CSS frontender creating a slick design for your site, while you work on the back-end.
Windows Forms has (as for now) more third-party controls available though, and if you don't really have a need for the stuff that WPF brings, then you certainly don't have to switch to WPF.
Have you seen WPF or WinForms, choose wisely ?
In short, WPF is the next UI platform for Microsoft Windows. It learns a lot of lessons from previous technologies, but the risk is immaturity of tooling and third-party components.
One benefit is the separation of concerns. You can build your application without worrying too much about UI stuff like layout, colours, fonts, etc. Then you can pass it to a designer who can make it look amazing (hopefully) without needing to understand code (using Blend or some other tool).
From a purely pragmatic point of view, my choice of which framework to employ is often down to which third-party controls I need to use (although you can use a WPF control in a WinForms app, for example - using hosting controls).
One more thing I like about WPF is that the core graphics processing has been shifted from GDI+ to DirectX. That makes a huge performance benefit when you are working on 3D or heavy grid/time series plotters as it tries to consume your GPU (graphical) resources rather than CPU.
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.
I just installed visio, and the installer almost seemed like it was built in flash.
The buttons kinda glowed when I hovered over them, and when I clicked on 'continue' the form phased out in a cool way.
I'm assuming it was built in WPF.
Anyhow, so are WPF more flash-like (visually speaking).
Do they have new properties where you can make forms phase out nicely/smoothly compared to winforms?
Disclaimer: I work for Microsoft. However, I don't work on Visio, WPF, CLR or Silverlight team. So, the following is my personal take on these technologies. If you want to quote me, don't do it implying it's the official Microsoft position. :-))
Update: Anything I say below about Flash/Flex/AIR might be wrong, as I have not worked with these technologies and what I know about them is based on what I read on the intertubes. :-) If you notice anything wrong, just shout in the comment and I'll correct it.
To the best of my knowledge, the Visio installer is not built with WPF. It's all unmanaged code; it's just people took a lot of care to make it really polished.
WPF is the new UI platform for building standalone applications for the Windows OS. It supports a declarative UI language - XAML, and related CLR types to program against. WPF is a different platform than WinForms, although it is possible to build applications that mix UI built with both. WPF supports a lot of things that WinForms does not, like bitmap effects, animations, control styling and so on and exposes them both in XAML or through code. Also, WPF relies heavily on vector graphics, as opposed to the pixel graphics in WinForms. In short, WPF is quite powerfull and allows building very snazzy UI. (Don't take my word for it, though, as I am biased; go check around for what people are saying about it or buiding with it. :-))
WPF and WinForms do not compete with Flash/Flex. WPF and WinForms are both UI frameworks for building standalone client applications. As far as I know, Flash/Flex are frameworks for building rich internet applications - RIA (though lately people started interpreting this abbreviation as rich interactive applications).
Adobe did come up with AIR about half a year (or maybe a year) ago, which allows building standalone client applications, so you could say that Adobe is trying to position Flash/Flex/AIR to compete with WPF. Of course, that's my take on it and I doubt Adobe's official positiong is anything like that.
If you want to compare particular MS technnologies with Flash/Flex, take a look at Silverlight - it's the MS RIA platform.
Silverlight is related to WPF in the sense that they share XAML and the corresponding CLR types. Silverlight supports only a subset of what WPF offers, though, as it is not targeting Windows OS only and thus is limited by the fact that it has to be portable.
Quick update to reflect the changes in the year since I've written the answer :-)
With Silverlight 3 shipped, SL and WPF are getting even closer and sharing bigger set of supported features. In addition, most of the new XAML controls are built for platform at the same time. Thus, SL/WPF are getting to a point of singularity...
Also, SL 3 supports out-of-browser applications. In that sense, SL is not only starting to compete with Flash/Flex, but it is also encroaching on AIR's turf.
And no, I still don't work on the WPF or Silverlight team. :-)
WPF is being used as a replacement for WinForms, and as a competitor to Flash in the form of Silverlight. WPF consists of an entirely new object model that sits on top of DirectX (at least the desktop version). You can create WPF windows, controls, etc, entirely using C# or another .Net language just like you can render WinForms. However, Microsoft has also created a markup language called XAML (eXensible Application Markup Language). Nodes in an XAML document (XML) map to objects in a similar fashion to the way ASP.Net maps to web controls. XAML typically exists in a .Net project alongside a code-behind style C# file (or VB.Net or whatever). The C# file interacts with the objects generated by the XAML. This is fairly consistent with the "graphics via markup, logic via code" model that Microsoft and others are pushing.
One of the overlooked features when discussing WPF is the completely awesome data-binding that Microsoft wrote for WPF. The new data binding framework is a quantum leap beyond Windows Forms 2.0 data-binding. Microsoft added a couple of new interfaces that make it much easier to make an object or collection emit data-biding events properly. They also provided a very rich set of data-binding classes. You can bind anything to just about anything else. You can bind one-way data to control, control to data, two-way control to data and back, control to control, etc.
Back on the graphics side of the house, WPF makes it fairly easy to make an existing control look like anything. WP lets you compose your own template for what a class of buttons should look like, or one button, or all buttons. Or radio buttons. Or labels. You get my drift. Imagine if CSS included the ability to define what an input button would look like using other HTML controls.
They also provide a number of layout controls. You can continue to use exact positioning like in WinForms, or you can leverage of variety of techniques to make your window act more like a web page that grows and shrinks with resizing, etc.
The downsides: It is too easy to create spectacular effects that crawl on slower machines. Some of the graphics do not take advantage of hardware of graphics cards, though Microsoft has incrementally improved support for this. I believe when 3.0 first came out drop shadows were rendered purely using software. I think 3.5 or 3.5 SP1 changed it so that WPF would utilize graphics hardware for the task. Microsoft has said they will continue to enhance WPF in this fashion.
WPF is .Net 3.0 and above, which runs on XP SP2, Vista, and Servers 03 & 08. So don't plan on deploying WPF to a customer with Win2k desktops.
Summary: If you are doing desktop programming in .Net, you should be doing it in WPF unless you are targeting Win2k. You can avoid the downsides of WPF, and there are many upsides. Microsoft will probably throw away WinForms in some future release, or at very least you will stop seeing new features, etc.
As far as Silverlight goes, the betas for SL 2.0 look good. I think that Silverlight will require some wide-spread adoption. Microsoft has already tried to get this going. The NBC Olypmics site used Silverlight, and Major League Baseball uses it for its MLB.tv product. As soon as Silverlight gets a good install base I think you will see the Microsoft side of the development world starting swinging away from Flash and to Silverlight.
Edit after using Silverlight 3 and MVVM:
I have moved away from WPF and am doing a lot of Silverlight 3 development. But I think my comments here will still apply to the WPF developer.
I have been using the MVVM pattern in my app (think MVC with a twist). The Microsoft Patterns and Practices team has released a set of libraries known as Prism that supports various aspects of MVVM. There are WPF and Silverlight versions. Take a look at MVVM and Prism if you are going to be doing WPF or Silverlight development.
You can do a lot of flash w/ Winforms, or with custom components. But if you want out-of-the-box bang-whizz availability, WPF is the way to go.
Yeah, I think the intention is to be flash-like, it seems to me that MS has set its sights on taking down Adobe.
The way I see it: WPF is to Flash as WinForms is to Flex. WPF has more emphasis on vectors and states than on programming.