Develop Reference

Writing cross-platform application with a complex GUI

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.

WPF or Windows Forms

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.

Is WPF a good choice for developing line of business user interfaces? [closed]

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.

Learning WPF and MVVM

I have recently joined a new developing project building a thick client application using WPF and MVVM. I have developed applications in various .NET frameworks from 1.1 through to 3.5 and all major technologies; WebForms, MVC and WinForms. On all of my projects I have enjoyed every minute of it but on this project I feel that I am struggling and as such not enjoying it as much. When .NET 3.5 came out in 2008 I really enjoyed learning the new language features (LINQ, MVC, Lambda Expressions, etc) and dabbled in WPF so please don't assume I'm against learning something new.
But the learning curve on this project seems really steep and I feel that learning MVVM on top of WPF + the application is a little daunting. Although I have only been on the project for a short time (2 weeks) I really like WPF but have taken a disliking to the MVVM pattern. My disliking to the MVVM pattern may because I don’t really understand it and I feel that I have to write a lot of “non best practice” code in order to do what was relatively simple in my WinForms days.
So my question is has anyone else faced a similar situation and did you stick with MVVM or go in another architectural direction?

I have been working with WPF since the beta versions and I would never go back to winforms. To me MVVM is a philosophy and it takes a lot of work and discipline to implement it faithfully. It encourages complete decoupling between UI and interaction logic which means no code behind whatsoever which means testable interaction logic which is very difficult to do with winforms.
In contrast to gius I would recommend you stick with plain WPF and MVVM especially if you are just starting out with WPF. There is a lot to grasp with MVVM and WPF, adding to that will just slow down your progress. But that's just my opinion. I always prefer to layer my learning rather than try to learn everything at once that way you are in control and you have more knowledge about how your application works.
If you have not already done so I strongly recommend you read the MS article on MVVM :
http://msdn.microsoft.com/en-us/magazine/dd419663.aspx
Its fantastic and it is compulsory reading for my team members who write any WPF code.
I am not sure how you and your team work but you need to ask yourselves whether or not MVVM is for you. If unit testing / test driven and decoupled UI is something you are already doing or is important to you then MVVM is definitely a good path to take. If your team is happy with writing code behind and you don't see why you should bother decoupling then don't bother with MVVM as you will find that it will slow you down. Personally the latter is never an option for me.
Please feel free to contact me if you have any specific questions about WPF or MVVM.

I have faced a similar situation, and the route I decided to go was:
Use ViewModels for my views, but avoid some MVVM pureness, like Attached Behaviors (which I find dumb and clunky)
Use Magellan MVC framework, which fit best my mental model about how an applications should behave.

I started learning WPF and quickly came across MVVM - it seemed like such a good fit that I've stuck with it. It's probably worth pointing out that there do seem to be some differences in the ways people implement MVVM, a key one being View-first or ViewModel-first. Some seem to see this as a point of gospel - I don't have enough experience to decide if it should be. I tend towards View-first (so View has a reference to ViewModel and ViewModel has a reference to Model and none in the other direction) but I have come across a scenario where the other way was easier.
Why not post some questions around the specific points you see as non-best-practice. It might help others wrestling with this subject as well.
One other question: are you using a specific framework for MVVM?

Well, before using MVVM, I used MVC in ASP.NET MVC framework. The Model-view-controller architecture is pretty obvious there so it helped me to change my attitude from standard ASP.NET and WinForms.
MVVM is a little bit "harder" to understand, but once you realise that WPF differs from web (you as a user respond back to the view, not to the controller), it makes sense to move from MVC to MVVM.
I suggest reading articles about MVVM on homepage of Caliburn project (left column, part 3. Study in MVVM) - this helped me a lot.
Regarding WPF (Silverlight) applications, I would strongly recommend to start building applications right on top of PRISM (Composite WPF) and/or Caliburn - although it might be confusing from the beginning, still it is a much better choice than with vanilla WPF (speaking about practices they force you to use). But take it for sure that once you have finished your first WPF application, you will want to rewrite it from scratch. But that's how it works when you learn a new technology.

MVVM is just a design pattern. You do not need it unless you are comfortable with WPF. If you are learning WPF, I suggest you first complete the book, then learn about MVVM. If you try learning both, you would try to implement MVVM in every simple WPF app or do not understand some feature of WPF that MVVM uses.
P.S: I came to this conclusion when I faced the problem myself. I still do not understand how the ViewModel can create a new View if it knows nothing about it.

WPF has a steep learning curve. So does MVVM. Which explains the feelings you have: getting to grips with both XAML and MVVM and trying to produce a real-world application at the same time is a daunting task.
I've trained .NET developers like you and helped them go over that learning curve quickly. Then packed that training into a quick-read book that you can get here:
Learn WPF MVVM ebook
Learn WPF MVVM paperback
It's also available on Amazon and major book sites.
Sorry if that sounds like self-advertising, but I really believe this books is 100% appropriate for your profile.

Which WinForms CompositeUI framework to choose?

my team is minutes before developing the head application for our company and we ran into roadblock in our design. my team develops WinForms application in C#, .NET 3.5.
The first thing we need to do in our design is to decide which CompositeUI framework to use.
Well, first we were sure that we are going to use CAB. but is it the right choice considering P&P are not into it any more?? What about Acropolis? Is it stable enough and going to be here for the next few years??
So this is my question: what is the framework that is stable enough and is right for an application that will lead my team for the next 3-4 years?
your help is needed.
thanks!

If you're going to do WinForms, the Smart Cient Software Factory is the way to go. From what I've seen in the market, most people are going away from WinForms and moving toward WPF. I'm in the process of evaluating what it will take for my company to move from WinForms to WPF at the moment. I love the support for WinForms right now, but if your time horizon is 3-4 years, I would strongly recommend you take a look at WPF instead.

If you want to stick to Winforms by all means, there are quite a few third-party solutions out there (for instance Empinia or the Genesis Hybrid Smartclient Framework being shown on CodeProject) as well besides the Smart Client Software Factory. The question here remains whether they're stable enough and have enough stamina to still be around in 3-4 years.
On the other hand, if you're looking at this fairly long time frame, considering WPF might really pay off. Yes, it's a learning curve, and yes, the tool support in VS 2008 isn't quite up to snuff just yet. But things will get a lot better with VS 2010, and Microsoft will be investing a lot of manpower in WPF - VS 2010 itself is written in WPF.
For WPF, there's P&P guidance in the form of Prism, which is very promising and looks very well thought out. Going into WPF also brings you additional benefits of basically knowing Silverlight "for free" (it's a subset of WPF, at its core). So that might be an additional benefit.
Marc

Glenn Block posted some guidelines a while ago that could be of interest.
And Brian Noyes actually did a port of parts of PRISM to WinForms but I don't know if it's good and stable enough to be used as your platform for the next couple of years. =)