I am a long time MFC programmer and know it quite well. Recently we are planning for a large desktop application. In order to beat competition, one requirement is polished UI. We narrow down the choices to three:
WinForms
MFC
QT4
We looked at some big WinForms applications, such as Paint.Net, and feel that it still lacks power of performance. The startup takes a while and some UI parts do not look very nice.
We had great hopes in QT4, but after writing several programs on it, we find that the looks of a QT4 application is not at par with native Windows UI. It still looks differently. Also we worry about about lack of widgets (for example, the color picker and calendar control in the library quite suck).
MFC is a safe bet, especially with components from Codejock.com. The UI interface looks quite polished with codeJock toolkit. And all widgets needed are there. The problem is that its coding style is quite outdated.
What will you choose for your next desktop application?
WinForms is effectively at the end of its life now. You should look at WPF.
See WPF: Any cool UI ideas i can look at? for links to some nice examples.
WinForms is really easy to get into if you know MFC (it's still based on the core Win32 concepts, so you don't need to learn much to get up to speed). Compared to MFC, you can develop much faster, and there is so much more library support for everything in .net that you have to write for yourself or find 3rd party libraries for in MFC. Often I find the .net solution to a big problem is around 3-10 lines of code, whereas the equivalent MFC solution would be hundreds or thousands of lines. I wouldn't even consider MFC a starter now that I've used WinForms in C#.
We're building some very large C# applications and the performance is perfectly fine. If any small part of the program is really performance-critical, it's really easy to plug in a bit of unmanaged C++. I found startup times abysmal in XP in the early days, but with more recent .nets and Vista, startup time is comparable to MFC apps.
So I'd go for WinForms/.net at a minimum.
WPF is also a sensible future-facing approach to consider.
WPF is a good option if you've got design skills or can ask for someone to prettify your UI. I think it's definitely one of the most versatile options.
You could also use components like DevExpress or Telerik, both have an extensive library of WinForms controls and as of recently WPF controls. I've used DevExpress myself and am rather pleased with the looks. Although these library don't come cheap, but they do carry quite a lot of functionality.
I've never worked with QT4 so can't judge that.
For my next desktop app I would use:
on Windows:
Probably the old fashioned Windows API (without MFC) because I am familiar with it.
Maybe Qt, because I'd like to try it out.
on MacOSX: Cocoa
on Linux: Qt
Not that I am very fond of MFC, but if you are comfortable with it, go ahead. It is not going away any time soon, although it surely won't be updated and improved as much as WPF.
Having spent 12+ years developing MFC applications, and now using WPF for less than a year, there is no way I would go back to MFC. At previous employers, we would spend countless hours customizing UI behavior and getting the right graphical look that would take a fraction of the time in WPF. Not to mention the added flexibility of being able to work with the UI as XAML (XML,) as opposed to the rather outdated resource editor.
If your application has to be C++ (as opposed to C#,) then I assume that using WPF would be a little more non-trivial. I haven't done .NET inside of C++, but I remember the overviews presenting it as a fair amount of extra work.
We at my work are currently revamping a GUI app from VB6 to make it look "prettier". We've chosen the .NET winforms platform for our upgrade since most of our coders are familiar with it. .NET has a few libraries dedicated to graphics, and there is a wide range of nice-looking user controls already built into the library. Asside from those, there are many, MANY custom-made controls out there such as the ComponentONE library, and there are a lot of opensource controls for enterprise use that look nice as well (you can search CodeProject.com's articles section for some free, downloadable controls that look very vista/windows 7-esk).
The framework also natively doublebuffers windows, and has bufferedGraphics classes that you can use to manually handle doublebuffering if you so choose.
However, windows forms do still ghost when dealing with high res images as background pictures and the only way to really fix it seems to be to use the DirectX libraries to draw using the graphics hardware on the machine (which is difficult, but atleast its free).
Hopefully that helps your decision on the platform form the windows-forms side.
I would still consider MFC. It's far from dead and especially with the new 2008 feature pack. You get a host of updates and can now create those fancy ribbon UI elements. If you already know MFC then you know the pitfalls (old but some are still there) and can knock out the work quite quickly.
There a ton of UI components you can buy for MFC and it has the benefit of being fairly close to the metal as far as speed goes. There is no need for your end users to install a framework or anything else.
I write C# for my day job, but all my personal projects are MFC/C++ since they don't require my users to have additional frameworks,libraries,etc installed.
Related
I don't ever really hear about Qyoto. My question is, is it still around and good to use? Would it be smart to use on one of my projects, or should I stick to gtk# or qt in another language? Are there any projects currently using Qyoto?
I write a small cross platform app in .Net. I originally wrote it on Windows with a WinForms UI. When I ported it to mono I found that the UI really suffered on Linux. In an effort to get a better Linux UI I rewrote the UI in GTK#. It is nice to have the designer, but GTK# is a terrible UI framework when coming from WinForms (never mind WPF). The fact that it is based off of a C framework really shows through. Many things show their procedural roots and it just doesn't feel very .Net centric. None of the controls understand the .Net Framework components. So, for example, you cannot bind a DataTable to a GTK grid control. Also, the documentation is very poor.
Since I use KDE on Linux I've been looking into Qyoto for a long time. Recently I got my application loading a Qt UI. I designed it with Qt Designer and convert the .ui file to C# with the uics tool. This extra step is a pain to someone who's used to Visual Studio. Additionally, Qyoto doesn't really integrate with .Net either. For example, the QT signal/slot mechanism is separate from the .Net event/eventhandler system. Again, the bolts and wires show through.
These and several other factors have forced me to move off of .Net for Linux GUI development. Again, since I use KDE, I will be sticking with Qt. My decision now is between Python and C++. Python is great for RAD, but I'm really looking for a great IDE and that is pushing me toward C++ (Qt Creator).
Last I checked, Qyoto was not stable on Windows. I'm currently using another .NET binding for Qt - qt4dotnet. Works fine but it you can't use Qt Designer with it and the API uses Java conventions because it's based on Qt Jambi. Also there is no integration between .NET events and Qt signals in qt4dotnet.
Update: Qyoto has recently been obsoleted, its successor is QtSharp.
Its very confusing, looks like Qyoto was originally based off another project called QtSharp. Now the new project is also called QtSharp :/
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 am tired of flickering of GUI and every possible control, milions of articles about double-buffering, ControlStyle flags and so on that don't even work; look at this examples:
How to prevent a Windows Forms TextBox from flickering on resize?
After reading this question, other on SO, and many articles on the web i think there are 2 options, write own controls, or use alternative to the winforms. So my question is: what are good alternatives that can be easily used with C# and .NET on Windows, and maybe even on Linux and Mac (but this is not necessary)? However if i missing something with all that windows mess, i will be glad if you correct me.
One important thing, altough flickering and other problems are annoying, they not prevent job getting done, so alternatives priority is to be fully functional, otherwise, it's better to stick with ancient winforms.
What about these alternatives?
WPF
GTK+
Qt
WPF, would be your answer to Windows Forms if you are on the .NET platform.
Have you seen this SO question? It might help you with the flickering problems.
I have never experienced flickering in my winform programs with VS2008 in C#.NET. However, if you want an alternative, you could always call the native WIN API functions. It is much more complicated than using winforms though, so you would probably regret it. You will have to write a LOT of code to populate and retrieve data from your controls.
The reason .NET was developed was to make programming easier (and to lock millions of programmers into the Microsoft platform). I am very happy with it. If you have invested the time to learn the .NET platform, I think you would be better off sticking with it. Each development system has its own peculiarities, and you may have more trouble than you would have with .NET, and it might be harder to find someone to help you when you have a problem.
If you are not prepared to consider using WPF, you could go for the native Qt with C# bindings but I think WPF is by far your best bet. Consider your coding style - if you are already used to using bindings and commands, or event handlers, WPF is the closest conceptually.
I don't think it's a good idea to consider using C# to call a native library but if you go that way, please let us know how it works out!
WPF or Silverlight (for web+desktop projects)
I am to develop an application on windows. I have never done that before ;-)
I need to do some heavy audio calculation, which has to be written in C/C++. This part will be a room correction algorithm which currently takes about 10 seconds per channel to run in Matlab. It has to be written in C/C++, since it might be ported to a DSP later on, which has to be programmed in C/C++.
Additionally, I need a GUI to review calculations, visualize results and modify calculation parameters. The tough part of this GUI will be lots of plotting of spectra, spectrograms, audio waveforms and the like.
Now, I hear that WPF is all the rage in Windows GUIs, but it seems to be limited to C#. Is there a simple way to integrate my C/C++ code with some C# GUI code? Or should I rather take WinForms and just write the whole thing in C++? Or would Qt work just as well and provide some cross-platform capabilities "for free"?
I have some experience with C/C++, Matlab and VST-development, but I never wrote a real application and honestly, I don't even know where to start.
Thank you in advance!
I think the biggest drawback to using WPF or WinForms is that you will have to program in two programming languages, which is a big logistics overhead.
I've seen this type of argument before: use C or C++ for low level, something else for high level. In this case Qt/C++ is as high level as WPF/WinForms, with the benefit of very easy integration of UI to your other C++ code.
For spectrograms and other graphs check out Qwt.
P.S: WPF is not all the rage on Windows, in fact the market is quite fragmented and WPF is one of the lesser used GUI toolkits. Most of the code out there uses MFC, WTL, Delphi, Win32, etc.
I have no experience on QT, but I can say that WPF is good but its not that good for high CPU intensive applications, plus you will not be able to directly integrate your c/c++ easily with WPF.
There will be huge learning curve and you will have to write COM Interfaces to communicate with C#/WPF and your native code. or Visual C++ .Net CLI, which is quite difficult and less tutorials are available.
But problem is you will not get any good support because lots of people only use C#, database apps only with WPF/WinForms. The best way to do is, you can write COM DLLs to integrate with WPF, but that will be difficult.
Instead there are various tools available now in MFC, and lot of other commercial libraries are available as well to write good UI in C++ MFC, where integration will be quite easier as you are familier with C++.
Or else Qt, if you already know it.
Libraries:
Prof-UIS
BCGSoft
There may be many, you can search for "MFC UI Elements", Library etc. I have used Prof-UIS way back in 2003-4 they are good.
WPF will tie you to Windows, but not to any language in particular. You can write WPF applications in C#, VB.NET, Managed C++ or any other .NET language.
Winforms is similarly tied to Windows, but you may be able to write your application in such a way that it also runs on Mono, and therefore is cross-platform. However, Winforms is far less capable toolkit when it comes to complex visualizations.
Interop between .NET and native applications is very strong, but it is sure to cause you at least a little pain. On the other hand, implementing the interface in a native environment may cause you even more pain.
If you're happy for your GUI to be tied to Windows and .NET, WPF is the best option for highly visual applications. If you don't want a dependency on .NET or Windows, Qt seems like your only option.
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.