I've been playing around with C# console applications for about a year and I want to move on to creating GUI applications. I have never done any GUI development besides basic Java applications, but I want to continue using C#. Should I start learning Windows Forms or jump straight to WPF? Is there a huge difference? Does WPF build on top of Windows Forms or are they totally different?
If you're just starting out, jump straight into WPF.
It will allow you to get starting making rich interfaces using mark-up to define your interface without teaching you the possible bad habits (for WPF) that you'd learn from Windows Forms.
These two are totally different technologies. They do offer some interoperability layers to both directions, but other than that have nothing in common. Windows Forms is more or less a lightweight wrapper on top of Win32/MFC, which means its extensibility in .NET is not that good in all cases. WPF is a new UI framework implemented from scratch. WPF is also much more flexible when it comes to customizing the existing types.
However, at least from my experience, Windows Forms seems to be the more commonly-used desktop UI framework in the industry. Windows Forms can't be used with web development though while WPF offers Silverlight and XBAP applications.
If you have done any UI development before, I'd dare say Windows Forms is easier to learn as it follows more traditional programming paradigms. The programming model of WPF is quite different to this. While WPF can be used in the same way as Windows Forms, most of its benefits are not achieved until you embrace the data binding and encapsulation WPF provides.
Despite stating some points in favor of Windows Forms choosing WPF over Windows Forms would be a no-brainer for me if all you want to do is learn a UI framework. It's superior to Windows Forms in all aspects. I just wish the software industry in general would adapt it on a larger scale! (Though not like anyone writes desktop applications any more since we got the web.)
Both technologies have their pro's and con's.
WPF is better for cross platform development and creating 'flashy' GUI's. However it requires a newer .net framework than WinForms and requires a dx9 compatible GPU or higher (which most people will have).
But it is a little bit more involved to create the interface / wire up all the events etc.
WinForms is still a powerful technology which can often be developed at a faster pace than WPF however, in the end, both technologies can be used to achieve the same thing. However WPF is the 'newer' standard.
WinForms is commonly used to develop business applications whereas WPF is often used to create more end-user based bits of software, apps etc.
WPF provides very rich facilities to build extremely complex user interfaces. It simplifies integration of a hardware-accelerated graphics in your interface. However, the Visual Studio WPF designer is really bad (I almost never use it). I also think that WPF is much more complex, and it is more difficult to start with. But this is subjective of course.
Related
We have a .NET 4.x project and a Qt 5.x project.
We would like to use one or more QWidgets from the Qt project in the .NET project. The widgets would ideally be added to a forms control if possible.
What is the recommended way to solve this issue? One option is to use ActiveX.
I've spent some time working on an application that mixed Win32, WPF, and several flavours of Qt, and you can get it to work although it may make a few of your hairs grey
You can host native controls in a WPF application: https://msdn.microsoft.com/library/aa970061(v=vs.100).aspx
Qt can be hosted in native Windows apps using the qtwinmigrate project https://github.com/qtproject/qt-solutions/tree/master/qtwinmigrate. Note - I've only used this to host dialogs, not embed individual controls, so I don't know thats actually a possibility. I've also had an extremely difficult time getting the messages pipes from all 3 systems to play nicely together, but it is (more or less) possible I think.
The real question is if you have WPF at your disposal, is it really worth getting the Qt in there? You would need to have a fairly large existing widget to justify the pain.
I am doing lot of desktop application but using .Net WinForm.
But now for productivity as WPF provide lot of further. I am stating to doing development using WPF.
We are developing small application not very large but lot of enhancement comes for most of application.
I am just want know which WPF framework/approach for WPF is good for me with considering following point
Framework is Simple to understand and manage
If support Fast Development its very good for us
New enhancement its easy to add
Its Support UI management
Support new further link LinQ, Entity Framework
WPF, in general, doesn't really require a framework. Choosing an appropriate framework really should happen after understanding the basics.
There are quite a few good, lightweight "frameworks" that help fill in the gaps, such as MVVM Light and Caliburn Micro.
However, if you're new to WPF, I'd start at the fundimentals, first. I wrote a series of articles on moving to WPF from Windows Forms which explains how to think about WPF, and why you should try to think differently than you do in Windows Forms. Often, when people first start using WPF, they make assumptions (like the requirement for a "framework") based on their Windows Forms experience, and waste a lot of time that could be better spent just building the application directly.
To not scary you, but WPF It is not simple, especially if you are moving from Windows Forms. I, personally think it would be easier to someone who never did before desktop development, or at least WindowsForms dev.
So if you are searching for something to learn fast and boost your productivity, it's not about that.
Wpf is about testability, reliabity and scallability which is really beautiful and I strongly encorage you to begin to learn it. But consider that you will need understand and learn it, write basically more code then, may be, you did in WinForms. But this is a pay you have to pay for most advanced, flexible and powerful windows desktop dev framework I ever worked with.
In short, you have to learn it:)
I'm about to start up a large project where the same database will be queried by three different applications/sources.
First application will be a WPF app for use on PC (duh)
Second will be this handheld device som PSION: http://www.psion.com/us/products/handheld/ep10_specifications.htm
And last there wil be a website (MVC3 I think)
For the WPF I think I'll go with with MVVM pattern (or will MVP make more sense maybe?), but when it comes to the handheld device, I'm clueless as to which pattern/arcitecture to choose. Is it even possible to have some sort of arcitecture on such a device?
Anyone got any experience with this? :-)
Any help/hint is appreciated!
/ Bo
If you are planning to use Windows Mobile 6.5 along with the .NET Compact Framework 3.5 SP1 (in Visual Studio 2008), the most common approach is to use Windows Forms (Compact). If you are planning to use C++, you can ignore the rest of this answer as I'm not sure what the best practices are for C++.
Windows Forms for .NET CF is similar to the full framework Windows Forms, but much more limited in functionality and out-of-the-box tools. There is really no WPF/Silverlight/MVVM options readily available for the legacy Windows Mobile platform, but you can try to roll your own MVVM type framework if you're brave, but I probably wouldn't suggest that as MVVM works better with WPF or Silverlight, and may not map to Windows Forms as well as other options.
There are several MVC or MVP examples or basic frameworks out there for .NET CF Windows Forms, but I haven't seen one that's really full-featured. You could try the "Smart Client Software Factory" for Windows Mobile from the Patterns & Practices team at Microsoft, but I'm not sure I would go that route, as it can be overly complicated. Search google for "Windows Mobile MVC or MVP". A lot of times the MVC/MVP examples only show a single screen, which does not give you any idea how the author intends to handle application screen transitions, global events, etc.
I would probably suggest the MVP pattern over MVC as MVP works well with Windows Forms. MVC can be a little awkward with Forms, unless you do it very carefully. This is the best example I've found of a multi-screen app on the Compact Framework using MVP in .NET CF:
https://github.com/derickbailey/appcontroller.cf
This is a great example, as it uses modern best practices like IoC and UI event aggregation. The other bonus of this example is that it sets the stage for good unit testing and good practices for UI development.
I’d like to develop an application with a complex GUI (combobox with animation, charts with spline, transparent layers, …). I have good experience with C# 2.0 and I’m studying WPF, but I read that, unfortunately, there is no plan to port WPF to Mono.
If I stick with C# and create custom GUI controls using OpenGL (via OpenTK), I feel it will be a hard work (integration with GTK#, debugging, hard to use to design forms).
I can use Java (with JOGL), but I’m not very skilled with it, and I don’t know about performance issues.
Last option is C++, but I have to do a big revision (years since last time I used it), and I find it hard to develop GUI and portable applications in C++. (Maybe I’m wrong! Still, I’m quite afraid to develop such complex application with this language.)
What is your advice? Had I better choose C# + OpenTK, Java + JOGL, or return to C++?
I would go with Qt. Take a look at http://qt.nokia.com/products/ . If you are afraid of C++ (but there is no reason to be afraid of it), you can try with Java Swing. I think that those are the best options to go with multi platform desktop GUI development.
I would suggest Mono and GTK#. Developing apps with .Net is far more effective than doing it in C++ vanilla. Sure, you have to stick with C# 3.0 and .Net 2.0 (some features from 3.5 is implemented, like LINQ). But it still gives you a lot more than C++ with, for instance QT, would give you.
Go C# for productivity. Nothing against C++ but it's a bit verbose.
As for the GUI library, I think WinForms used to work on Mono. Alternatively, GTK#.
I would not suggest using wpf for it is a platform dependant platform. Silverlight might be a better option.
But if you are developing a web application, jquery would be a nice option you also might consider adobe flex and adobe air; http://www.adobe.com/products/air/
Does multi-platform have to include iDevices? Can it be on the web? Those are 2 questions you have to answer first.
If you can live without iPad/iPhone suppport, then Flex/Flash/Air is good option for highly graphical things. It is multi-platform for sure and easily integrates to the web. Probably your best option for this case with the limited details given.
Qt could work for you as well, although I can't say for sure if it's graphic library will make it easy. I've personally never worked with it, so other would have to answer that. But since it is in C++, you could use other libraries as well.
Java Swing sounds rough to me for this complex of a GUI. Making some basic stuff isn't too bad, but if you are expecting an experience like with C# I think you will be frustrated. Just a personal opinion of course.
Lastly, if it can be a web app, why not stick with C# and Silverlight? A .NET solution may work well for you since you are already learning it.
Silverlight runs on Windows/Mac/Linux and some handhelds, and is being ported to more handhelds. I believe Silverlight will ultimately be ported to every popular device.
Silverlight is:
Much, much more powerful than Flex/Flash/Air.
Much, much more powerful than Qt.
Ridiculously more powerful than GTK+ or GTK#.
Ridiculously more powerful than JOGL.
Silverlight has all of the features you have requested.
Silverlight works very well with C#, which is a much more productive language to work in than C++.
Silverlight is basically a very large subset of WPF, so if you already know WPF, you already know Silverlight.
Unless you absolutely require iPhone/iPad support I think the decision is perfectly obvious.
See this comparison of WPF and Cocoa to get some feeling of how WPF/Silverlight compares with the likes of Qt, Flash/Flex/Air, and GTK#, all of which use a primitive WinForms-like object model similar to the one used by Cocoa.
At my day job (a well-known microprocessor company) we develop complex engineering apps with Java, Eclipse RCP, and Java OpenGL. Performance is good -- we can easily get many millions of polygons/second and up to 100 frames/second. The SWT widgets in Eclipse are fast enough where we haven't had to render any custom controls with JOGL.
I've got a set of tutorials that shows how to get started with this kind of programming. The series starts with http://wadeawalker.wordpress.com/2010/10/09/tutorial-a-cross-platform-workbench-program-using-java-opengl-and-eclipse/.
First, don’t use C# for anything that should be portable. Mono is a bad option for GUI for two reasons:
Mono goes always several steps behind .NET.
Mono does not support WPF, so the only way to develop GUI is using something like GTK#.
My personal opinion – use C++. It would give you very good portability and independence.
You have two options:
Qt4 – very good GUI toolkit, makes GUI development very easy, and highly portable.
GTKmm – also very good toolkit, but it feels less natural on Windows.
Also, Java has Swing toolkit that comes with JDK and is available on all Java platforms, even very strange ones like OpenVMS.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 1 year ago.
Improve this question
We're debating whether our future Windows UI development should be WinForms or WPF. How have some of you made this decision? Most of our applications are LOB applications, and I'm not sure I see a clear and overwhelming benefit to WPF for these types of applications. However, my knowledge of WPF is limited. I'm also a little concerned that WPF will be in vogue for another couple years and then Microsoft will get tired of it and push something else on us. I guess one argument against this is the fact that Visual Studio 2010 is a WPF application.
Thanks.
There are a lot of factors to consider here.
Reasons not to choose WPF:
It currently has less support than WinForms for common LOB controls like date pickers, numeric entry widgets, and so on, though this is improving via the WPF Toolkit, in WPF 4 and through third party control vendors.
The tooling isn't fit to kiss the Windows Forms designer's boots. (Though to be fair this is partly because the tooling has to cope with much more sophisticated ways of constructing views. And Blend is definitely getting there.)
A very different mental model to Windows Forms. To get real benefits out of WPF, you need to think in a very different way to what you're used to. So there may be a substantial learning curve -- not just in terms of learning the technology, but in terms of internalising the idioms and patterns (though there are now a lot more community resources around idiomatic WPF than there used to be).
Reasons to choose WPF:
Decent architectural support. WPF (if you do it right) has a decent separation of code and UI built in, making WPF applications much easier to test and to evolve.
Greater flexibility. For example, if you need a simple map display, you can build it in a couple of hours from a ListBox, instead of having to research and purchase a third party component or write a map control from the ground up. Simple data visualisation is a killer feature for WPF.
WinForms is a dead end. It's not going to see any enhancements from Microsoft, and control vendors are already beginning to shift to WPF as the WinForms market saturates.
Most of your WPF experience can be ported to Silverlight, which (a) gives you flexibility to bring your apps to the browser and the phone, and (b) gives you additional confidence that Microsoft won't lose interest -- even if they do get "tired" of WPF, they've shown a very strong commitment to Silverlight.
Personally, if I were starting a Windows desktop app now, I would choose WPF. However, I've already climbed the learning curve. For a team that doesn't have WPF experience, the cost of taking it on must be a greater factor than it is for me.
One thing to bear in mind is Silverlight. Is it possible that you'll want to write your application to be run from a browser in the future, or possibly even from a Windows Phone 7 device? While Silverlight and WPF aren't quite the same, they're extremely similar. This would be my primary "future-proofing" argument in favour of WPF.
Personally I like the composition model of WPF - as well as a declarative way of representing the UI, and a better layout system than WinForms. Not that I'm a UI guy, really.
WPF is a game-changer for me. My company's flagship application is a WinForms program whose UI is build dynamically at runtime from metadata. It was about six months' effort, all told, to get the UI even stable, let alone attractive. There are still some bugs that I haven't been able to fix, largely because UI code is hopelessly and unavoidably intertwined with data-model code. And don't get me started on window handles.
Now that the system's been in production for a year or so, customers are coming to me with requests like, "We'd like to be able to reorder the information on this screen by dragging and dropping," and "Can we get this information to display in a grid on this part of this tab?" and - my favorite - "Can we get spell-check and auto-text?" Those requests go onto a backlog that's getting pretty damn long.
It's taken me a fair amount of time to figure out how to refactor the application's design so that it can support a WPF UI. (Actually, that's a considerable understatement. I've been grappling with this off and on for a year and a half, and I only started getting traction on it once I broke out of the WPF books I was working from and learned MVVM.) Once I did, the results are spectacular.
The code is much simpler. There's much less logic to debug. Everything in the UI is much faster, which is important because the whole reason this is a desktop app in the first place is that we needed a very responsive UI. My program can create thousands of UI controls without my having to worry about window handles. The ease with which I'm able to change the look and feel of the program is jaw-dropping.
(An example: The UI presents DataRows with a variety of templates. Since a given screen can have dozens of rows on it, and the cursor is kind of small, it's useful for the user to be able to tell, at a glance, what row the cursor is in. It took me ten minutes to implement the styles that now make this visual affordance available everywhere in my application. That's less time than it would take me to estimate that feature if I wanted to add it to my WinForms app. Granted, it would have taken a lot longer if it couldn't be done by adding two styles. WPF's is seriously not magic.)
Are there downsides? As Ms. Palin likes to say, you betcha. Browse some of the questions I've asked on SO - the one about how a no-op value converter changed the behavior of data binding is a good one. The entire rub-your-belly-while-patting-your-head approach to debugging bindings is pretty frustrating, especially since it's so easy to have binding errors and not even know it. (I now keep my Output window on the screen at all times just so that if there are any binding errors while I'm testing, the movement of the messages getting logged will catch my eye.) It would be nice to be able to get a real stack trace when your window throws a XamlParseException. Don't start me talking, I could talk all night.
And the tools! Visual Studio's visual tools for building WPF UIs is completely useless to me. I have Blend, and have used it to re-template a control, but in general I find using Blend to be like trying to jog through a swamp full of hubcaps and baling wire. I'm sure it's really awesome if all you know is Blend, but if what you learned first is the WPF object model and XAML, the behavior of Blend is pretty mysterious. The XML editors in Visual Studio and Kaxaml give me a sad, and Resharper's WPF functionality is, let us say, a work in progress. I much, much prefer the tools for WinForms that make it possible for me to smoothly and rapidly build the slow, quirky, and unmaintainable crows' nest of code that I'm coming to loathe.
WPF looks set to replace Winforms, at least on Windows Mobile devices, with future development focused around Silverlight (a WPF spinoff) and XNA.
In an open market, it makes sense to cover WPF if you want to keep yourself attractive to a wider recruitment market.
I've wondered that myself. But the fact that VS2010, like you said, makes a lot of use out of WPF says to me that Microsoft is trying to tell the world that it's not just another MS fad, but it's going to stay around for some time.
I think MS is sending a clear message that WPF and Silverlight are the present and future. The Winforms PM has said as much. Additionally, WPF and Silverlight are expected to converge in the future.
We went through this same dilemma about 6 months ago at my office. We were starting a large LOB app and no one on the team had a lot of experience in WPF or Winforms. That being the case, we couldn't find an overwhelming reason to go with Winforms and we felt that WPF offered us a much cleaner separation of concerns. We decided to go with WPF and use PRISM as the app framework. 6 months on, I think we made the right choice.
Knowing both, I really hope that WPF is the future. Windows Forms has incredible pain points, e.g. regarding Data Binding, and it's pretty much a thin film of .NET on a lot of existing stuff. When I had to debug into classes like BindingSource, it scared the hell out of me. Now, I don't know how the WPF classes look inside, but Microsoft is bound to have learned something between 2001 and 2006.
I love WPF because of
styling
data templates
excellent and first class data binding support
declarative UI set-up
atached properties
...
I can only hope that Microsoft will make more use internally of this UI technology, thereby reducing its weaknesses which have mostly to do with performance. WPF is fairly demanding.
In VS2010 I hope to see designers that will show off the power of the UI (the XML Schema designer in the Beta already looked pretty useful). I would think that an App like MS Word would profit a lot from all the transformation capabilities of WPF.
WPF is a great framework for creating apps. And when you combine it with a good GUI architecture such as MVC, MVP or MVVM it is brilliant at making interesting looking line-of-business apps with more pizazz than your standard WinForms application.
XAML on the other hand is the ugly cousin that comes along with WPF. The main issue with XAML is the tooling. The tools are worse than non-existent, because they make people think that there is a WPF designer like WinForms, when infact most devs I know use the equivalent of notepad to develop their XAML.
The other tooling issue with XAML is the compiler. XAML is only slightly better than magic strings. The compiler can't pick up most mistakes you make in XAML, and some mistakes won't even crash your app. Instead WPF will print an error message to your output and carry on.
Being that they essentially ditched winddows mobile for Windows Phone 7 which will only use WPF and XNA as its main UI layer I would have to say yes. One could even consider this move as an expiriment for the much more widely deployed Windows OS. That and most users love dumbed down eye candy IMHO.
On the question of tooling, I will concede that building WPF and Silverlight Apps in Visual Studio 2008's designer has required quite a bit of expertise to get right. However I hope you'll give a look to the improved designer in Visual Studio 2010 - it has many more features that we hope will make sense to the Windows Forms developer for building business forms, whether in Silverlight or WPF.
Check out these videos:
Data Binding and Forms Tools
Styling Tools
Futures
New Features in Beta 2
And get the Release Candidate here:
The team has a new Blog here
I hope you find this useful info - if you've already tried Visual Studio 2010 I'd love to hear your feedback. Send me mail at mwthomas at microsoft dot com.
Thanks
Mark Wilson-Thomas
Program Manager, WPF & Silverlight Designer, Visual Studio
IMHO, Microsoft gave some clues about it's future path by developing VS 2010 in WPF.
WPF is no more, no less than WinForms. It has a totally different and extensible way of UX design.