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.
Related
I saw a lot of question on this topic and it took me some time to decide whether or not I would write another one ... but I think my question is a bit more complicated ... so here we go.
I'm currently working with a WPF application using MVVM.
The application is built with:
WPF
Prism V2
Ideablade (devforce) to access a database
Avalon dock for the docking feature
Telerik for the grid component
Views and ViewModel are generated with .tt file.
Views are generated in xaml (for WPF) files.
I know that:
Telerik has Silverlight controls
Using Prism V2 will probably help me doing a Silverlight version of the application
I don't know:
If the usage of devforce can be a show stopper
If the usage of avalon dock can be a show stopper
My question:
Appart from generating xaml for Silverlight ... where do I start ...
----EDIT----
Please, avoid any comments like "Silverlight will die" or "Silverlight xaml is a subset of WPF xaml".
It is a proof of concept and should be made using Silverlight. For the xaml, I can modify the application to use only simple ui element that can be both in Silverlight and WPF.
Depending on how you actually used Prism and other frameworks this can be a lot of work or quite easy.
I'd start at the 'bottom' because I'd expect the Models and ViewModels to be quite portable, at least that is what I have experienced so far. She fact that Silverlight more or less forces you to write async code everywhere might encourage you to investigate in (yet another) framework such as Rx
The Views could be quite a hassle; you will have to find controls that provide the same features that you are using in WPF, build them or invent something new. That can be a lot of work.
Another thing to consider is when your WPF app relies on many desktop features you might consider creating an Out of Browser Silverlight App.
As with any project try to find areas that will probably need a lot of attention and do those first; it's a waste of time to get a lot of stuff working to find out later that you will have to replace it because of an impossibility elsewhere.
I want to implement UI for stock charting application. (I already have an engine working which will provide the data for the UI - the engine is in C#).
The app will update charts in real time as stock price change (candlestick charts, bar charts, line charts etc..).
I wanted to know what technology will suit best for my requirement: WinForms or WPF?
If you're doing greenfield application development I would probably suggest WPF to WinForms.
Pros:
Less code and better separation: with WPF supporting bindings instead of having to write the app following the MVC pattern with the Controller layer being thick, you can create it following the MVVM pattern, having a relatively lightweight ViewModel
Easy to reuse almost all of the code you write and port to Silverlight or Windows Phone 7 later down the way. Porting Windows Forms code to the web or mobile is much more painful
More charting libraries actively developed for WPF: there are a handful of vendors providing and constantly updating their charting libraries for WPF. Vendors include Visiblox Charts (see an example trading application in Silverlight - should be the same in WPF due to ease of porting of code), Telerik RadChart and Infragristics xamChart
Cons:
Speed might be an issue - with GDI you can render tens of thousands of points on screen and animate them seamlessly, this gets slower in WPF. (Though it seems WPF / Silverlight is getting better at this: see the zooming functionality of a Silverlight chart with 6000 points onscreen)
Without knowing more about your requirements, I'd say you'll be fine with either. However, it may be worth knowing that thirdparty control vendors appear to focus more on their xaml controls than their older Winforms ones nowadays.
For example, you might want to use Infragistics's XamDataChart which is quite a bit fancier and has more finance charting features than their older WinChart (I'm sure the same is true for Xceed's and Telerik's equivalents and am not pushing Infragistics in particular.)
The WPF toolkit (http://wpf.codeplex.com/) has charting already built into it, you just need to plug-in the data (which you already have). It has full support for all sorts of graphs, not to mention animations and custom styling.
This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
What is the difference between WPF and Silverlight application?
What are the exact differences between WPF and Silverlight?
That's an extremely broad question. My company recently wrote a whitepaper outlining the differences between the two technologies, and it's around 70 pages. Unfortunately, it's not published yet, or I'd give you the link.
EDIT: As promised, here's the link
to the whitepaper on Codeplex:
http://wpfslguidance.codeplex.com/
However, I'll try to summarize.
WPF is a thick Windows client platform that has access to the full .Net Framework. Silverlight is a browser-based technology that has access to a subset of the .Net Framework (called the CoreCLR). So, you'll notice differences using seemingly every day methods and objects within the framework. For instance, the Split() method on the String class has 3 overrides in Silverlight, but 6 in the .Net Framework. You'll see differences like this a lot.
Within WPF, all visually rendering elements derive from the Visual base class. Within Silverlight, they do not; instead, they derive from Control. Both technologies, however, eventual derive from the DependencyObject class up the hierarchy.
WPF, currently, ships or has available more user controls than Silverlight; though this difference is being mitigated through the Silverlight Toolkit and the upcoming release of Silverlight 3.
WPF supports 3 types of routed events (direct, bubbling, and tunneling). Silverlight supports direct and bubbling only.
There's quite a few data-binding differences that will be somewhat mitigated with the next version of Silverlight. Currently, Silverlight doesn't support the binding mode, OneWayToSource, or Explict UpdateSourceTriggers. In addition, Silverlight defaults to OneWay databinding if none is set, while WPF uses the default mode specified by the dependency property.
Silveright doesn't support MultiBinding.
Silverlight supports the XmlDataProvider but not the ObjectDataProvider. WPF supports both.
Silverlight can only make asynchronous network calls. WPF has access to the full .Net networking stack and can make any type of call. Also, currently, Silverlight supports SOAP, but can not handle SOAP fault exceptions natively (this may change in Silverlight 3).
There are huge differences in Cryptography (Silverlight has 20 classes in the namespace, while WPF has access to 107). Basically, Silverlight supports only 4 hashing algorithms and the AES encryption protocol.
Silverlight doesn't yet support: Commanding, Validation, Printing, XPS Documents, Speech, 3D, Freezable objects, or InterOp with the Windows Desktop; all of which are available in WPF.
Silverlight supports browser interop, more media streaming options including timeline markers, and Deep Zoom. WPF doesn't support these features yet.
This is by no means complete as I was trying to reduce a 70-page document into bullet points.
Finally, even with all these differences, Microsoft is trying to close the gap between the two technologies. The Silverlight Toolkit and the WPF Toolkit both address some of the shortcomings of each technology. Silverlight 3 will be adding many features not currently available (such as element-to-element data binding). However, due to the differences in the core libraries, there will always be some Framework differences.
WPF is a Windows desktop technology for developing Windows application in the .Net framework.
Silverlight is a web technology, that is fully supported by a browser plugin on both Windows and MAC (in a similar fashion to Flash). There is also a plugin for running Silverlight on Linux (Moonlight).
While there are similarities between the functionality provided by both WPF and Silverlight (in terms of user interface components and support for XAML) Silverlight is a much small framework, containing a subset of WPF functionality. Newer versions of Silverlight actually contain some functionality not found in WPF, so it is no longer a true subset.
Things that WPF has that Silverlight doesn't: Full 3d engine based on DirectX, Windows integration such as Windows 7 taskbar thumbnails and system registry availability as well as access to the full .NET Framework including Oracle database support. Also, SL runs in a secure sandbox that prevents access to things such as the entire file system where WPF apps can run full trust with complete system access.
As mentioned above, SL pioneered some technologies such as the VisualStateManager which are making their was secondarily into WPF through the Microsoft supported WPF toolkit.
If you're looking to gauge which technology is right for your project here's a simple way to look at it: If you're writing an app that's meant to run while disconnected from the web, or if you're writing an app that needs access to Windows specific features like the ones listed above then WPF is the way to go. For platform-agnostic, web enabled apps Silverlight is an appropriate choice. Hth.
You could say that it is [VERY] roughly analogous to the difference between Flex and Adobe Air, but that is somewhat misleading.
WPF refers to the set of technologies (exposed via APIs) that .NET Framework 3.0 and above users have access to in order to draw to the screen.
Many of the WPF APIs are available for Silverlight apps.
There are, of course many other APIs besides WPF that are available under Silverlight since SL apps will need to do a lot more than just draw on the screen.
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 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.