I've been looking at WPF, but I've never really worked in it (except for 15 minutes, which prompted this question). I looked at this post but its really about the "Flash" of a WPF. So what is the difference between a Windows Forms application and a WPF application?
WPF is a vector graphics based UI presentation layer where WinForms is not. Why is that important/interesting? By being vector based, it allows the presentation layer to smoothly scale UI elements to any size without distortion.
WPF is also a composable presentation system, which means that pretty much any UI element can be made up of any other UI element. This allows you to easily build up complex UI elements from simpler ones.
WPF is also fully databinding aware, which means that you can bind any property of a UI element to a .NET object (or a property/method of an object), a property of another UI element, or data. Yes, WinForms supports databinding but in a much more limited way.
Finally, WPF is "skinable" or "themeable", which means that as a developer you can use a list box because those are the behaviors you need but someone can "skin" it to look like something completely different.
Think of a list box of images. You want the content to actually be the image but you still want list box behaviors. This is completely trivial to do in WPF by simply using a listbox and changing the content presentation to contain an image rather than text.
A good way of looking at this might start with asking what exactly Winforms is.
Both Winforms and WPF are frameworks designed to make the UI layer of an application easier to code. The really old folks around here might be able to speak about how writing the windows version of "Hello, World" could take 4 pages or so of code. Also, rocks were a good deal softer then and we had to fight of giant lizards while we coded. The Winforms library and designer takes a lot of the common tasks and makes them easier to write.
WPF does the same thing, but with the awareness that those common tasks might now include much more visually interesting things, in addition to including a lot of things that Winforms did not necessarily consider to be part of the UI layer. The way WPF supports commanding, triggers, and databinding are all great parts of the framework, but the core reason for it is the same core reason Winforms had for existing in the first place.
WPFs improvement here is that, instead of giving you the option of either writing a completely custom control from scratch or forcing you to use a single set of controls with limited customization capabilities, you may now separate the function of a control from its appearance. The ability to describe how our controls look in XAML and keep that separate from how the controls work in code is very similar to the HTML/Code model that web programmers are used to working with.
A good WPF application follows the same model that a good Winforms application would; keeping as much stuff as possible out of the UI layer. The core logic of the application and the data layer should be the same, but there are now easier ways of making the visuals more impressive, which is likely why most of the information you've seen on it involves the flashier visual stuff. If you're looking to learn WPF, you can actually start by using it almost exactly as you would Winforms and then refactoring the other features in as you grasp them. For an excellent example of this, I highly recommend Scott Hanselman's series of blog posts on the development of BabySmash, which start here. It's a great walkthrough of the process, both in code and in thought.
To answer your question, a WPF application is a Windows application. WPF is Microsoft's new framework (actually, it is a subsystem of the .NET framework 3.0) for writing rich Windows applications. It is meant as an eventual replacement for WinForms (although admittedly the adoption rate is much slower than MS hoped for).
WPF stands for Windows Presentation Foundation. While WinForms technology depends on GDI/GDI+, WPF is built directly on top of DirectX. That means you can do much more than you can with WinForms, while getting still using the .NET Framework Class library. You can build rich user interfaces, 2D/3D games, presentations and much more. WPF is much like a Flash (swf) movie, without the element "Movie". WPF is based on .NET and can be used to build rich client side web enabled applications.
Start here, there's dozens and dozens of videos: http://www.windowsclient.net/learn
In this case, the marketing schpiel is pretty good:
**"Windows Forms is a set of classes in the .NET Framework that enables rapid development of rich Windows client applications, with powerful, extensible libraries for user-interface controls and graphics. You can incorporate WPF in your Windows Forms applications through WPF-Windows Forms interoperability in the .NET 3.5 Framework."*
*"WPF, a component of Microsoft .NET Framework 3.5, empowers you to build the next-generation of Windows user experiences. WPF supports UI, media, documents, hardware acceleration, vector graphics, scalability to different form factors, interactive data visualization, and superior content readability."**
With WPF you get WAY better graphics support, way more powerful and flexible databinding (if you're working with Data, use WPF.)
WPF is essentially a new API for creating a Graphical User Interfaces for the Windows Platform.
WPF is more than just a next-generation presentation system for building Windows Client application along with visually stunning user interfaces.
WPF is builds on top of the DirectX (Direct3D), instead of relying on the older GDI/GDI+ subsystem.
WPF is a vector graphics based UI presentation layer and being vector based it allows the presentation layer to smoothly scale UI elements to any size without distortion.
WPF is “skin-able” and “theme-able”. It means WPF allows changing the look and feel of any UI control.
From an implementation perspective, one of the main differences is that WPF uses a strictly enforced model-view-viewmodel M-V-VM architecture, with the view being defined in a custom markup language, XAML, the viewmodel being a class with accessible properties, and the model effectively being the data access layer. WinForms, by comparison, has no such explicit separation - although by convention the different aspects may be grouped in different C# files, its all still code. In practice this makes WPF development more like web DOM development, with the WPF framework running in the background and mediating.
Related
As far as I understand, I can use Windows Forms in Windows 8 Pro (non-RT) applications. However I was wondering if I can develop an app which has a nice WinRT interface for the main part as well as a WinForms part for the more complicated parts which benefit from stuff like TreeViews and which are complicated and useless to reimplement. Which development environment would I need for that?
Windows Store Applications are intentionally limited and do not include the entire .NET Framework, including Windows Forms, and WPF/Windows Presentation Foundation. You cannot mix the two components. They are executed and managed in very different ways (see here for details about how Windows Store apps are executed).
However I was wondering if I can develop an app which has a nice WinRT
interface for the main part as well as a WinForms part for the more
complicated parts which benefit from stuff like TreeViews and which
are complicated and useless to reimplement.
Even communicating from a traditional Win32 application to a Windows Store application is prohibited (for applications released via the Store -- see here for a discussion). So, building your application in two pieces really isn't very practical (and the user experience of swapping between the two applications may be unpleasant for many users).
There's an intentional design and usability model for designing a Windows App Store application that must be considered when developing a touch friendly application that does not lend itself to a typical Windows Forms application. Tree views for example might be replaced with a group/detail/detail type navigation.
I'd highly recommend you read through, if you haven't already, the UX guide for developing Windows Store apps. A transition between a modern UI application and a Windows Form application would be jarring to say the least, unless you spent an tremendous amount of effort trying to mimic the general UI principles established for a Windows Store application. While it's possible to do, and there are some 3rd parties that may provide reasonable components, it's never really going to be truly the same (and probably not worth the engineering effort to try to make it identical).
Some might suggest that you consider instead using WPF. Depending on the type of application and the current skill set of the developers, that might be a good fit for your needs. Again, there are 3rd party resources for mimicking the style of a modern Windows Store application that you could apply to your application if desired.
There can be a very steep learning curve for WPF if you have a reasonably complex data-entry/manipulation style application where you may need robust data validation, etc., typical of a line-of-business application. It's also hard to tell where Microsoft is going with technology these days -- WPF, while not deprecated, certainly isn't being enhanced like it once was. As Visual Studio 2012+ depend on it heavily, WPF isn't going away, but expect fewer new features. It's a robust platform generally speaking though, and it may meet your needs as is.
You may want to go through the exercise of modeling your application as a Windows Store application to see if the widgets and functionality you would need are present. Depending on your requirements, you may find that not everything is there yet (Windows 8.1 has some new goodies, so look at those too!).
Also, if you're familiar with JavaScript, you might also want to look at creating your application using WinJS. It's super powerful and can often use many existing JavaScript/HTML solutions, assuming they meet your UI and functional requirements.
WinRT UI components can only be used in windows store apps and Windows Forms only in desktop apps so you will not be able to mixed both.
If you are looking into making a desktop app for windows 8, maybe you should look into using WPF.
If you are looking into making a windows store app, there is plenty of third party control libraries which have a TreeView including the WinRT xaml toolkit .
I'm developing WinForms application. By far I've finished about 50% percent of it.
Is there anyway I can convert it into a Web Application without rewriting the whole GUI?
If there is non, in what platform should I use instead (rewriting my project) for having easily both Web and Windows UI?
Is there anything new in this subject in the last 3 years?
I know of course WPF and Silverlight are quite alike, but I'm not sure this is the bust solution.
This will be dependant on how you have constructed your architecture. The main reason WPF and Silverlight are interchangeable are because they tend to use MVVM patterns and architecture (also things like PRISM)
http://msdn.microsoft.com/en-us/library/ff921075(v=pandp.20).aspx
In theory if you follow the pattern you can drop the front whenever you like and and design it using something completetly different. This is known as:
Making your UI loosely coupled.
If you wanted to switch your front end display to a web application you would obviously have to change the UI layer to use HTML, in theory if you have given your application a suitable architecture your business logic should be able to remain the same, however if you have a lot of logic tied into the multiple Windows Forms i'm afraid you will suffer a long and painful migration process with many bugs along the way.
Think of your application as a house - you have the main foundations for the house (insulation, bricks etc.) which you may want to change from time to time to bring the structure up to date, however the fundamental foundations will normally remain the same. You can however decorate the house with however you wish without affecting the fundamentals (sorry for a poor analogy).
Hope this helps somewhat.
EDIT:
I just noticed you wanted to know the best architecture to use with a project, personally from what I know I would use PRISM, WPF and MVVM - you can Build WPF and Silverlight Applications with a Single Code Base Using Prism
Our team is experienced working on Winforms and ASP.net projects.
As what other programmers in programmers stack exchange recommend me to jump to WPF for our team next projects instead of using WinForms for our Client based business Applications.
Now i am starting to Develop my first project using WPF, its a little bit tricky for me as its my first attempt to use this.
Can you gave much deeper information why we need to jump to WPF instead of using winforms?
I need to convinced our manager that we can dig on WPF for our client based projects.
We are using VS 2008.
Pick up a good MVVM Framework. I personally use Microsoft Prism. For other alternatives, look at this StackOverflow question.
Routed Events are for the view only. For example, if you want to scroll to the end of a multiline textbox when the text changes.
Commands are used to bind events in which the logic resides on the view-model (business logic)... For example, a submit button.
If you have designers on your team, get them to start playing around with Expression Blend and understanding styles/layout. Expression Blend allows you to use sample data to see your applications layout without having to run it all the time.
Understand The difference between ContentControl and ContentPresenter.
Understand how ItemsControls work. There is a difference between SelectedItem, SelectedValue, and SelectedValuePath.
Look at a lot of exmaples online. Dr. Wpf, WPFTutorial.net, Josh Smith on WPF, etc.
If you plan to take advantage of Code UI Testing (to test the actual User Interface), then make sure to name controls that matter (most MVVM tutorials tell you that you shouldn't have to name any controls). If you don't plan on doing Coded UI Testing, then don't name your controls unless you need to reference them from the view itself.
IValueConverter and IMultiValueConverter should only be used to convert properties to view-related items. The most commonly used converter is the BooleanToVisiblity converter.
TargetNullValue, FallbackValue, and StringFormat are important when using binding. Don't make assumptions that the data being bound will always be available and correct.
You will almost always expose ObservableCollection<T> or ReadOnlyObservableCollection<T> from your view-models. Very rarely will you ever return any other type of collection, including an IEnumerable<T>.
Be careful in choosing your BindingMode: OneWay, OneTime, TwoWay, OneWayToSource (WARNING: OneWayToSource is tricky... it still requires a getter because it is not a write-only binding).
A good debugging tool that is free is Snoop. It is similar to a DOM explorer for a running WPF application. A more advanced (and not free) tool that is a bit more powerful is Mole.
That's all I can think of for now... Oh, and if you run into road blocks, StackOverflow is your friend :)
I wrote a series on WPF with MVVM specifically targeting developers who have a Windows Forms background, and are planning to jump ship.
It walks through some of the basics of WPF, showing how it allows you to approach your development differently than Windows Forms, including introducing (gently) templating, commands, and other concepts that tie into the vastly superior data binding in WPF.
This would provide a nice introduction to WPF, and show you why it can be better for business applications than Windows Forms.
For those that are reading and wondering "why WPF" instead of Winforms, the answer is that the WPF databinding makes it a heck of a lot easier. MVVM really is just to help you get the most of out of it, but you don't strictly need it.
As someone who is learning just now, I'd recommend just taking WPF out for a spin, open up a project and start doing what you did in WinForms, manually assigning properties and handling events. It will work. But, once you figure out that WPF does this automatically for you, you'll suddenly start to resent the old way, and you'll wind up following the merry path of MVVM.
When learning the C# language. With all the applications being developed these days. Would I be better off focusing on windows forms development or WPF development. I want to develop software that uses ADO.net for SQL Server database access. Also stand alone applications to integrate with Microsoft Office to create charts and graphs etc...
Although for the purposes of Windows UI that both can achieve similar results, their function is independent of one another as is their purpose.
WinForms is tried and true, non-evolving due to strong roots. It does not mean WinForms is deprecated. It just means that the foundation classes for WinForms are well established and flexible. Keep in mind the flexibility in extending WinForms via the Control class and deep-engineering UI messaging (via handles exposed by the WinForms classes).
WPF however is an abstraction layer to design user interfaces, not necessarily or exclusively Windows user interfaces. The most difficult hurdle to leap is transitioning from the thought of coordinate based user interfaces (pixel/bitmap/index) to vector based user interfaces where WPF can adapt to virtually any size control or plane of rendering.
The benefit of WPF is that you're learning three different targets for your applications - Windows UI, SilverLight, and now Windows Phone. WinForms targets Windows UI and Windows Mobile (CE). A clean UI based on common widgets has an appropriate foundation in WinForms. If a customized, dynamic UI is your target, take WPF for a spin.
I'd be using WPF as it also allows you to do Silverlight applications using the same XAML markup.
Having said that, there are horses for courses so you need to choose the appropriate tool for the job. That does mean you need to know both to make an informed decision. :)
The learning curve with WPF is definitely much steeper - at the same time you can easily whip up some simple UI in Windows Forms to fill your needs in regards to ADO.net or SQL Server database access. Once you add charts/graphs to the mix, you are going to want to learn WPF hands down though.
Also you might want to look at Lightswitch, which takes care of some of the complexity with Silverlight/WPF.
Though WPF is the future and it gives you so much flexibility, I don't recommend switching completely to WPF. Also, you will be able to make the most out of WPF if you have a designer that will be able to work on the design part. I'm not saying you need to have a designer but based on my experience with WPF, if you want to develop a killer looking application, you definitely need to have some one that knows the bits and bytes of WPF. Just as BrokenGlass said, the learning curve with WPF is too steep. So, just make a gradual switch. If you already have some Windows Form applications, try to rewrite some of those in WPF.
The kind of stuff you're trying to do can be done with both WinForms and WPF. WinForms is a more familiar paradigm but (big but) XAML in general, WPF in particular, is not the future but the current way of doing Windows UI's in .NET, WinForms being the past it is basically in maintenance mode (good for existing apps, dare I say obsolete for new apps). Yes, XAML posses a somewhat steep learning curve, but the abilities you get are worth the effort, besides there are more and more resources (books, libraries) on XAML/WPF/Silverlight while for WinForms there are plenty but stagnant (I haven't seen any new edition of a WinForms book in a couple of years). One thing worth noting is the databinding capacities of XAML which render unnecesary many of the code moving data from/to objects/datasets to/from visual controls.
WPF and XAML is a learning curve but my experience is can build more powerful, concise, and supportable applications in in less time. Can copy and paste XAML from one page to another. On Windows Forms I gave up on copy and past of UI elements from one page (form) to another as too many times it locked the whole app. Two way data binding is a dream. WPF UI has a more commercial grade look. Portability to Silverlight. For me it is 98% of what I would get from C++ in a fraction of the effort.
As your prime objective is to learn C# you should concentrate more on language features rather then your UI. You should try to learn and use various features of C# and what all it supports and how. Learning(C#) will be much more in developing Business layer and Data layer of your application rather then your UI; so you should concentrate on building these layers first(with any presentation framework).
I am not sure whether you have any prior experience in any of console applications, WinForms, WPF or ASP.net but for learning purpose you should pick one you are most comfortable with. In case you are starting a fresh then I would suggest you to first start with WinForms as you will be writing a lot of C# code in WinForms then in WPF, and later pick up WPF.
My answer is totally focused on fact that your prime goal is to learn C# and not on which UI framework is better etc.
I'm about to start developing a small Windows application using Microsoft Visual C# 2008 (Express edition). I'm very new to C# and .NET, so this is a newbie question. Should I start with WPF or should I stick with the old WinForms?
My application has several screens, all having several text-boxes, check-boxes, combo-boxes, not anything more. The application will retrieve data from several COM objects, and communicate through standard TCP/IP sockets, both of which are unrelated to the UI.
The UI is not fancy in any way (and I don't need it to be). However, the world seems to be moving to WPF. What are the considerations of choosing WPF over WinForms for my case? What's the recommended approach?
Thanks
I have not used Forms enough to say anything about which is better, but I have found WPF to be easy enough to use for minor applications.
I figure that if it's the standard people are moving towards and it's not difficult, then it's good practice to start using it.
WPF = Future + Fancy stuff
WinForms = WYSIWYG greatness
Choose whichever of the above you find the most atractive :)
It depends. Stick with WinForms if you're comfortable with it.
If you want to be able to have a better look-and-feel with more customized controls, and you're willing to spend the time to learn XAML and the differences between WPF and WinForms, then go for it. But expect it to take some time, there is a learning curve.
Interesting, how all answers target the developer: familiarity with a framework, the learning curve, the technical features of a framework etc.
If it's a simple application, none of the technical aspects really matter. You sound like you have some experience programming, in that case the chosen framework doesnt really matter. Focus on your users instead.
Can you guarantee that your users have the latest .net runtime installed? Are they willing/able to install it if they dont?
Will your users be put off by an "outdated" look and feel?
The way you phrased your question, i think you should use WinForms. You seem to imply ("stick with winforms") that you have experience in WinForms and that you dont have any fancy demands for the UI, so i see no reason to put yourself on a steep learning curve that WPF can be.
I personally like alot of the things that WPF provides. It has easy data binding, validation, and customizing UI things is simple. Plus with the new Expression Blend 3.0 that was released yesterday they have sketchflow WPF apps that you can share with others and get feedback files from. It is a pretty interesting little addition to the WPF world.
The nice thing is that if you find a Winform control or something that needs to be WPF and you picked the other way, they seem to work well with each other now.
It's a trade-off.
You will most likely be more productive starting off in Windows Forms because the programming paradigm is closer to most other UI development libraries you might be familiar with. There are also many libraries of UI control available for WinForms (including ActiveX) that make creation of attractive, functional UI easier. Unfortunately, MS has indicated that WinForms will not see any more advancement in the future because their emphasis is on WPF.
WPF, on the other hand, is more more sophisticated and robust and can help you create very attractive, rich interfaces. WPF sometimes requires the use of more sophisticated back-end programming paradigms like MVVM to create effective applications. Also, as a newer technology, there are fewer mature libraries and tools to help you develop WPF apps. For development tools you have VS2008 and Expression Blend (which is quite nice BTW). Advanced graphics features like gradients, color themes, skinning, control customization are all more powerful in WPF. But this power comes at a price - most developers find WPF to have a more significant learning curve that WinForms.
WPF is something completely new if you are used to WinForms, so it'll take quite a while to get used to it. But i prefer WPF not because of the looks, for me it's more the great layout system (once you got used to it), its databinding infrastructure and in combination with patterns like MVVM, the separation of UI and business logic.