So I've been learning C# for like a year now (I'm 20 years old) and I'm getting pretty confident with it. I've also been meddling with C++ every now and again. For example just recently I've been following the Nehe OpenGL tutorials for C++ and I find it a fun way of learning.
I want to start looking at creating cross platform GUI software after I stumbled across this library called FLTK (fluid something rather). After finally and painfully getting it to work I found it refreshing to know that there are solutions for GUI creation in C++, however I think FLTK looked pretty old.
So I googled around for some newer GUI frameworks and decided to start playing with wxWidgets (decided against Qt because of licensing).
I downloaded it, compiled it, and looked to see if there were any IDE plug-ins for RAD development, as you can imagine going from drag and drop a component onto a form in C# I was hoping for something similar.
I learned that code::blocks has something of the sort so I tried that out. It was alright but the thing that turned me off was the horrible code completion; it would only show members and methods in the current object and nothing for the #included header files. I understand that code completion/IntelliSense isn't easy for C++ but Visual Studio 2008 handles it pretty good. I did find some other RAD tools like wxFormBuilder but it costs money, not something I want to do for simply learning.
So my TLDR question is if anyone has had experience with wxWidgets? Do you just develop in whatever IDE you're comfortable with and just code the GUI? Meaning no visual helpers? Perhaps you could give me a nudge in what direction I should be going :)
Thanks, this is also my first post on this site albeit I have read many threads before that have helped me solve copious problems. Cheers!
My suggestion is to learn how to do GUI layout with wxWidgets in code, then when you get good at it learn how to use the GUI tools.
Doing this kind of work manually for a while gives you the understanding about what you need ("Ok, I need a wxSizer, vertical, to put these two horizontal wxSizers into, where I put my a wxStaticText and a wxTextCtl for each line ...")... where as I think if you started out with the GUI tools you'd just tend to get annoyed because (last time I looked) none of them were Drag And Drop editors like you get with .NET.
Definitely give Code::Blocks another try. It is a WONDERFUL environment to work with wxWidgets in. It comes with a form designer and templates for wxWidgets projects, so I can't imagine working without it.
Also, for a good beginner's introduction to wxWidgets, try this page. It helped me alot when I started with it.
I use wxWidgets without using a drag and drop designer. There are obviously drawbacks to that approach but an advantage is that you don't have any horrible automatically generated code to deal with. In the past I've found having such code in the middle of my project has caused various types of grief - especially if you decide it needs some serious changes it is often necessary to start from scratch because form designers are so much better at "writing" as opposed to "editing".
For simple applications you can assemble a UI using a mixture of customized and standard widgets without too much difficulty. Check out the wxWidgets samples and demos, which use that approach. My chess app (see my website) uses this approach too.
A more elaborate UI could possibly be implemented by writing something special at a higher level of abstraction. The kind of thing I am thinking of would be a subsystem that accepts high level flexible requests to provide different types of user interface functionality, and then sorts out the details of the controls to create and the positioning etc. of those controls itself. That is kind of a technical fantasy of mine but I haven't ever really attempted to do it. Actually, a fairly primitive facility of this type is already available and used by the demos I mentioned; It is called a "Sizer" (class wxSizer) and is basically a control container.
Finally I would point out that problems with the Qt licence have basically gone away since Nokia bought Trolltech and made it "more" free (LGPL licence). Many people think Qt is the way to go these days. I am pretty happy with wxWidgets but will definitely evaluate Qyt seriously one day. Good luck with your projects.
I have developed a number of application GUIs using wxWidgets - you can see screenshots at http://ravenspoint.com/
IMHO, you should distinguish between designing a GUI and implementing it. Expecting to use the same program to design your GUI and to automatically emit all the code to implement the design is expecting too much.
A design program should be fast and simple. I recommend http://www.balsamiq.com/
Once you have settled on the design, then you can turn to the coding. Personally, I find that placing widgets on a panel using the wxPosition and wxSize parameters of the wxWidget constructors to be trivial - easier than trying to nudge widgets into their exact positions using the mouse.
The trouble with using some kind of form builder to emit all the code for a significant GUI is that you end up with a morass of automatically generated code that is hard to find your way around in. If the code has been handwritten, then you already know where everything is located.
wxFormBuilder but it costs money
wxFormBuilder is Free and Open source
Also Visual Studio is best for C++ coding in wxWidgets, but you will run into lots of issues on Linux due to the way Visual Studio handles a lot of things, like file names you have to take extra care for case sensitivity.
Also regarding the GUI, add the wxFormBuilder to the Visual Studio solution, add the file type handler to Visual Studio. Now just double click on it and add your dialogs, like you do it in C#.
Just add the generated code files to the Visual Studio project once and you are done.
It's very easy to use Visual Studio with GUI programming in wxWidgets.
Also don't forget to watch the CodeLite editor if you want to port on Linux. It is very much compatible with the Visual Studio projects and shortcut keys.
There is wxGlade and wxFormBuilder.
I don't know if there is another one, but the wxFormBuilder I know is free and open source.
You will find links to other tools on the homepage
of wxGlade (http:// wxglade.sourceforge.net/).
Most of these programs are able to output xrc files, which are are an XML representation of your GUI. It address the issue of complexity of the generated code but is not as powerful.
Yet personally I don't use any of these tools, except sometimes to see what it's going to look like before I do it but never to actually generate code.
I just finished doing a hello world program in both wx and fltk using the netbeans IDE. Microsoft Visual Studio WinForms or MFC was much easier than either. I needed cross platform capability so I could not use it for this application. I finished fltk in much less time than wx. The program was simpler, smaller, faster, and easier to write. Wx had pretty disjointed documentation and organization. Fltk was designed back in the "old days" when small fast and efficient was valued. That's probably why it seems "old" to you. I'm an old guy so it worked for me. YMMV
Related
I want to start developing desktop java applications and I would like to know what the java community uses.
I started with Swing but I found it very rudimentary.
I'm used to work with .net c# WPF with Visual Studio 2010 and I was looking for something with the same quality (or close) with java ( Swing + Window builder is not an option )
I would appreciate your inputs, even if you disagree with my Swing opinion
thanks all
The other option you want want to look into is SWT (The toolkit Eclipse uses). It renders using mostly native components so it feels more robust like a real desktop application.
I'm looking for a better looking and feel development..
Swing offers 4 PLAFs as standard. There are at least a dozen more 3rd party PLAFs, some with dozens of variants. Of that plethora of possibilities, end-users generally prefer the 'native' PLAF - which looks and feels mostly like 'every other native app.' on their machine.
You can see a small app. that changes PLAF. on the Nested Layout Example. Here is the Mac. native PLAF.
..why do you think it is not easy?
This was said in relation to a general comment that it is harder to build a GUI in Swing than (for example) Visual Studio.
The reason for that is that Swing is intended to work on multiple platforms, screen-resolutions/sizes, PLAFs (and other factors). As such, 'dragging and dropping' components into their final position is impractical, since that might change according to the factors listed above. Instead Java relies on the concept of layout managers, which calculate the size and position of components as they appear at run-time.
The layout managers use 'logical groupings' of components to achieve the desired general shape expected of a GUI. The image above is an example of how to combine layouts to achieve different effects in different parts of the GUI.
Although I don't use GUI builders for Java I do feel that they can increase productivity, it is just a matter of:
Already knowing what Java Layouts are available, and how to use them.
Using the standard layouts in combination in the GUI, to achieve the desired effect.
If you don't mind an external dependency, you could also take a look at SWT. It's the framework that eclipse is built with, though it's not the easiest thing in the world to use.
It does provide a GUI-builder called SWT designer (if I remember correctly). It's not as good as what you're used to in Visual Studio though. That's a pretty high bar for quality. In the brief experience I have with it, there was a fair amount of boiler plate code, and the API isn't quite as intuitive as I'd like personally.
However, it is fairly widely used. Eclipse is built on it, and by extension, so are many professional tools built from that same base (Such as IBM's Rational tools, and Adobe's ColdFusion Builder). That should give you an idea of the power of the tool, if nothing else.
How about Java under Mono,using IVKM and Gtk?
You would be able to program in java, but your application would actually be .NET code... Not sure if that works for you.
If you want to move away from .NET alltogether, then perhaps you could use the java Gtk bindings:
http://java-gnome.sourceforge.net/
Check out JFormDesigner. JFormDesigner with Eclipse is a very powerful tool set. Also look for a good LaF. See The Alloy Look and Feel and JGoodies. You may find Look and feel in java useful.
I wanted to learn to program and looked at both Java and C#. I decided to go with C# because it was so easy to just open a form and plop some buttons and text boxes on it. With just one download, C# Express got me going.
From what I saw with Java that couldn’t be done. At least not without downloading and configuring other software. All of which I found no easy instructions for. But I really wanted to learn Java.
I really don’t want to learn how to create UIs AND a new language. I’d rather just to concentrate on the code itself. Is there an easy way (like C# basically) to create Java apps?
Are you talking about a GUI builder?
There are many GUI builders out there. Some IDEs like Netbeans come with nice GUI builders for Java.
There are options in the Java community for 'one-stop downloads' like you mention. They are out there, they're just not as public as Visual Studio is. EasyEclipse is one of my favorites.
I've done a fair bit of work (> 4 years) on both platforms and the biggest difference I have found is not so much with the languages per se, but with the whole development environment. Specifically:
In .Net (be it ASP.Net, C# or VB.Net) the examples you find on MSDN or elsewhere tend to just work without a whole lot of tweaking, and the documentation is more reliable, whereas Java examples - especially the open source ones - often don't work out of the box and the documentation (yes, Apache Slide and Shindig - I'm looking at YOU!) is sometimes non-existent.
Having said that, the sheer amount of choice for plugins, libraries and the like for the Java platform is enormous, which is unsurprising considering its (largely) non-proprietary nature.
It seems to me the best and easier way to get what you want is to use Netbeans (JDK 6u14 with NetBeans IDE 6.5.1 Bundle).
It has both the JDK and the IDE in one download. And it has a easy and very good GUI builder.
Java is a very good platform and as you said it is easier to create cross platform applications, however, don't except this from the Desktop UI which, although still cross platform, not always gets right on all platforms with out modification.
You would have to add some code specific for each target desktop, but definitely that's a lot easier than write three different application ( One in Visual C#, other in GTK, and other in Cocoa )
I been learning to program in C# for a few months, but recently I signed up for a course which required Java. So I started playing around with java, first tried Netbeans then Eclipse.
I'm kinda a computer programming noobie (background mainly in web design) so take my perspective as a student. After messing around with Java for a bit i still prefer C#. While both are excellent the factors that tipped C# in my case are as follows
Easier documentation and a large variety of easy to view Video Tutorials, yes I know netbeans have a very large collection of video tutorials as well, they are encoded at such a terrible resolution and bitrate that they are largely unwatchable
Slightly easier to learn, maybe it's cause of the IDE or the syntax, but I found C# easier to pick up.
More functionality exposed right after using the IDE, you will find more controls in visual studio than compared to Netbeans. Eclipse was quite confusing for a noobie like me wading through it's massive plugins.
I think the only thing java has going for it, is that it's supported on more platforms. Though Mono is making up for the linux and Apple side so i guess it's not that bad. Either way they are both extremely productive environments, just in my humble noobie opninion C# is just slightly more intuitive to pick up.
The ability to learn to program in one language or another should most certainly not be based upon how to drag and drop GUI controls, especially since that measure is irrelevant to the language itself.
Side note: Java and C# are so similar that you'll pretty much be learning both as you go regardless.
I'd have to agree with dxmio, I switch back and forth between c# and java quite often. The two languages are quite similar.
The best way of learning programming .. is to write code!
If you know your way around Java, It's a mater of syntax to learn C#.
Programming is just as much a way of thinking in code, as knowing a language.
Personally, I didn't start with GUI. I started with BlueJ, a free "learning" compiler, for Java code.
No programmer in the world knows any language 100%. Their all sitting in their office, and playing with stackoverflow and google all day. Remember, Google is your best friend! (May be a bit of caffe too !)
Reminder: The best way to learn to write code, is to write code! If it's C, C++, C#, Java, PHP, Python or whatever you prefer, it's a matter of framework and syntax.
If you have Java in your browser, all you need is the latest Eclipse bundle.
I would suggest the Java EE edition for your platform from http://www.eclipse.org/downloads/
It appears that there are video tutorials starting from scratch at http://eclipsetutorial.sourceforge.net/totalbeginner.html
Using Netbeans, you can create Java based Swing GUIs pretty easily. Netbeans comes with a pretty nice GUI builder.
If you learn how to program in Java, I don't think it would really be that much of a stretch to create Java Swing applications from scratch. It's just a matter of learning the Swing libraries.
Not being from a .NET background, I can't comment on learning C# GUIs, but from my experience Swing was very easy to learn and it helps A LOT to understand the code underlying what the GUI builder in Netbeans generates.
I decided to go with C# because it was so easy to just open a form and plop some buttons and text boxes on it.
You can do this using builders in either language without writing any code.
With just one download, C# Express got me going.
Netbeans is the same deal for Java.
From what I saw with Java that couldn’t be done. At least not with out downloading and configuring other software.
True, you cannot develop Java with C# Express and you cannot develop in c~ using Netbeans. You do need to install two pieces of software.
All of which I found no easy instructions for.
I suggest you try http://www.google.co.uk/search?q=netbeans+gui+builder+tutorials 55,100 hits or http://www.google.co.uk/search?q=java+gui+tutorials 1,340,000 hits
But I really wanted to learn Java.
It doesn't appear you want to actually write any code or install more than one program at a time. You will find that learning to program in a language will be asking more from you than this.
Was I missing something?
Quite a bit I imagine.
I really don’t want to have to learn how to create UI’s AND a new language.
You can use a GUI builder to layout your windows, but if you want your program to do something useful, you will have to do some programing in a language.
I’d rather just want to concentrate on the code itself.
That appears to contradict everything you have just said. You can't concentrate on the code without learning the language.
Is there an easy way (like C# basically) to create Java apps?
To write apps that do something useful you are going to have to learn how to program and at least one language. I suggest you also learn how to debug and profile your program.
i found this for designing java winform application for you .
please check out
www.formdev.com
JFormDesigner™ is a professional GUI designer for Java™ Swing user interfaces. Its outstanding support for JGoodies FormLayout, GroupLayout (Free Design), TableLayout and GridBagLayout makes it easy to create professional looking forms.
I recently started playing with C#, but I am finding it very frustrating. It seems every time I want to add what I think is a simple control, I end up either scouring the internet or writing my own. I just feel like I spend more time recreating controls to get them to work the way they should, and less time actually creating applications.
For example: In another question, I asked if it was possible to remove the border on a combobox; something I thought should be built into the control, but alas I had to build my own control for this simple alteration.
Am I just too new to C#/.net, or am I just expecting too much? I know SO loves C# so don't bite my head off for feeling this way, just help me understand what I am missing and whether I should continue learning and working with C#.
I spent 4+ hours today tracking down an 8 byte memory leak in a C++ program. There are threads involved and attaching the debugger would alter the thread timing so I couldn't do even something as simple as breaking on the Nth alloc to see where the leak was. Additionally I knew generally in between which two events the memory was allocated. Unfortunately both threads thought that was a great time to allocate lots and lots of 8 byte size objects. At the end of the investigation I found a ref count error on a COM pointer was leading to the leak.
Not having to pull your hair out over investigations like this is why you should move to C#.
For example. In another question I asked if it was possible to remove the border on a combobox; something I thought should be built into the control, but alas I had to build my own control for this simple alteration.
Of course you can't remove the border on combo boxes. They are Win32 controls and they have to play by the rules of Win32. That inlcudes giving the OS and the user, not the application control over styling.
If you want something you can style completely on Windows then you need to look at WPF.
I think what you really mean is:
Windows Forms on .NET is increasing my development time - am I missing something?
I think you are missing several things:
Open mindedness - with any new programming language comes not only new syntax, but new paradigms. If you come from C++ paradigms such as garbage collection may sound "too automatic" from you and you'd like to have more control but alas, you have to let go. Whenever you jump from one paradigm to another the prerequisite is always the ability to unlearn what you've always known.
Windows controls aren't the same as web controls - I've checked your previous questions and they look like you've been from VBScript, which probably means that you use it either from Office or ASP Classic. That being said your demand for controls that were easy to conjure when you were in the web would be much tougher for Windows -- Windows was not designed to be easily modifiable. That's why WPF/Silverlight was made.
Productivity is a function of ability to learn - There, I said it. It might hurt but, if you have cynicism or hostility blocking your learning process, you will simply not become productive soon. If you've been used to not having to learn new things, you will also not become productive soon. If you think you're really good at learning new things you will find ways to become productive in that language -- and then we can discuss about merits of your arguments vis-a-vis development time.
With any new technology there is a substantial learning curve at first, and some have a higher learning curve then others. I think you will see as you gain more experience that these things become substantially easier. C# has a lot of power with the .Net architecture to leverage from, but a lot of it takes time to really appreciate. C# is also changing and growing to allow for new coding styles (newer versions incorporate a lot of influences from functional programming) that keep it both in vogue and powerful. Stick with it and keep learning.
You're not the first, nor the last developer to have this sentiment. It always seemed to me that every time I needed to do something that wasn't part of a demo, I had to spend hours trying to figure out how to accomplish one small task. Much of my frustration was with ASP.NET web controls.
That being said, I found that once I got over the (steep IMHO) learning curve of control development, many of my frustrations were eliminated. I feel that using inheritance and overriding virtual members to create new behavior is a very clean approach. Plus, it creates output that can be very easily reused. Using OO practices just always seemed better to me than pasting JavaScript snippets all over the place.
Microsoft does a good job of providing many base controls to use out of the box, but every application always seems to need something that's missing. I would recommend learning control development, or looking to third party solutions if possible. There are many companies that exist solely to fill the voids. Either way, I wouldn't judge the whole language based off of the default control set.
It sounds like you are just new to it. It's not C# that's the problem it's the .net framework. If you used VB.net for example you'd likely have the same issue.
I went through this issue when I went from classic ASP to ASP.net. For half a year or so I felt the things I wanted to do in ASP.net were so much easier in classic ASP. Eventually that went away. Now I'm going through it again as I try to learn ASP.net MVC. Things I could do in 5 minutes in ASP.net are taking me days to figure out in ASP.net MVC.
In your case it sounds like you are using windows forms. Were you working with winforms before (i.e. VB6)? If you want more control over styling you might want to look at WPF.
Yes. You are missing something -- experience with the tools you are using.
For example, a few months ago I decided that my next project would be in ASP.NET MVC. I had been doing WebForms for several years and had dabbled with RubyOnRails for a couple of personal apps. MVC fit in with my desire to increase the testability of my apps and I prefer writing my own HTML for the most part anyway.
Despite my experience with ASP.NET, C#, and experience with MVC in RoR, it still took my awhile to match the velocity I had with WebForms. I felt like I had to spend all my time looking for how to do stuff. Now, a few months later I feel like I'm able to develop just as quickly as before. More to the point, I know the various paradigms and can apply them easily when faced with a similar problem to one I've solved before. I'm also building up a collection of extensions, snippets, and components that can be reused over and over.
I suggest that you give C#/.NET a chance for long enough to get over the inevitable early struggle and then decide whether it's the technology that's the problem.
Could it be that what you're trying to do is not, let's say, common? Most GUI developers follow some sort of human interface guidelines so that their application fits in well with the window manager of the OS being used. It helps with the user experience. Most GUI elements are designed with this in mind. So, it could be that you're trying to make your interface radically different than most, and thus, are finding that you have to do some custom work. That would be normal.
Depends on where you are coming from. I find c# to be very effective.
I rarely if ever use other controls as they often do not work 100% to my use cases and they create dependencies on your app.
So when you want to upgrade your project to c# 4 and can't because control X Y and Z don't work in c# 4 ... your SOL.
So I just take the hit up front and write my own controls which causes less grief later.
I'm a little ashamed for asking this, because, you know, I've been very anti-MS for a long time. I have been fortunate enough as to make a living outside Visual Studio. As I grown older there are "some" things I would like to try, and to be very honest, this Q&A site has inspired me and I realize that VS and Windows Development doesn't suck that much. Hey, after all C# was designed after Java, and now Java is copying back some features from the child language. And Windows vista is the first decent version since windows came to light.
Anyway, to any +3,000 user in the audience, you may delete all the above crap and keep the following:
Do you have, links, resources, tutorial aimed to learn Windows development coming from strong Java background?
I'm very interested in Windows manipulation (that is the actual window, the frame, get the name, get foremost app etc., resize it programatically, etc.) and in Windows Search API among other minor API's. My interest after all is to integrate them with my Java apps through JNI or JNA.
I've read many tutorials and links over the MSDN, and I actually understand the API it self. I've grabbed a copy of C# and C++ Express and actually got some basic samples running.
My problem is I don't get the big picture of the whole architecture (because, well, it is big). The classes have hundreds of methods, and it not that clear to me who calls them. (I had this same opinion when I first look at the Java's Javadoc API.) I don't know some basic common objects, for instance HWCD (or something like that) that it turned out to be the very window handler, but every single tutorial I read give that for granted (as if WHCD or what ever it is, was a very descriptive name).
I don't know exactly the difference between Win32, COM, COM+, DCOM, Windows SDK ADO, and some other technologies. I mean, I know them at some degree and by common sense, but while reading the tutorials or the API I get confused. I've tried to grab some "beginner" tutorials, but they are aimed for absolute 0 programmers using Visual Basic (yiak! , THAT was the main reason I kept away from MS for so many years in first place.)
I do understand .NET framework, managed code, unmanaged code, C# basics, CLR and related stuff, because well, they are SO similar to the Java platform that it is almost transparent.
So, after all my rants and honest opinions about MS development:
What's the best way to learn Windows Development for a non absolute beginner (in programming) but absolute new to Windows APIs itself? What would be a good path?
The Petzold is your new best friend, and MSDN is your new Javadocs. Make sure you have a good understanding of C before you dive into it though. The Forger has a great beginner tutorial too if you're interested. A great place to hang out while learning is #WinProg on efnet irc, plenty of win32 gurus ready to help.
I'm going to suggest an alternate path (with less resistance). Have you looked at WPF yet? It's the new GUI toolkit that lets you create sexy interfaces (like those found in Vista).
That may be enough to keep you interested while easing into more advanced development. From there you can jump into the jungle of the Win APIs (if you choose).
Just a thought, as that path would be more interesting for me. Your mileage may vary, of course.
I strongly recommend getting yourself a copy of "Win32 Programming". It explains the basic DNA of WINDOWS - and this is valid if you are programming with the old C++ win32, the new C# WinForms and also the future Windows Presentation Foundation.
In a nutshell, a Windows program consists of a WinMain. When first started the app registers its window class with the system, initializes and then starts a message loop which continues till WM_QUIT is encountered. The system (OS) keeps pumping messages like keyboard or mouse click etc to the message Q of the application. In Windows, at any point of time there is only one active Window - so the OS knows whom to send the message to.
Well things like these are described in detail in the above book.
COM (COM+, DCOM) are not really related to Windows. When Word, Excel became popular and it was required to be able to access Excel from Word (viceversa) they came up with the AcitveX technology which is kind of the root for COM etc. You can get started with "Essential COM" by Don Box.
One warning: in the Microsoft world, there are two ways to program - to go the boiler plate way (write everything yourself) or use frameworks (MFC, ATL-COM....). It is recommended to do a bit of boiler plate so that you know the basics.
Having made the same conversion a year ago I can say that there's a lot of literature specifically for learning c# from a Java background. This was my first into which I found really useful for learning the important differences / features of C#:
C# from a Java developer's perspective
And there are also books which may be worth a look at (google 'c# for java programmers'). As JohnT said MSDN library is the equivalent of JavaDocs API, but I found it really frustrating to use. The best way to learn is to grab a copy of Visual Studio express and start playing around. Use intellisense to explore classes and methods. Find a small program you wrote in Java and try to reproduce it in C#. Start with simple problems, use google to solve them. You'll find it hard for the first week, but trust me, it will come to you surprisingly quickly!
My company has developed a long standing product using MFC in Visual C++ as the defacto standard for UI development. Our codebase contains ALOT of legacy/archaic code which must be kept operational. Some of this code is older than me (originally written in the late 70s) and some members of our team are still on Visual Studio 6.
However, a conclusion has thankfully been reached internally that our product is looking somewhat antiquated compared to our competitors', and that something needs to be done.
I am currently working on a new area of the UI which is quite separate from the rest of the product. I have therefore been given the chance to try out 'new' technology stacks as a sort of proving ground before the long process of moving over the rest of the UI begins.
I have been using C# with Windows Forms and the .net framework for a while in my spare time and enjoy it, but am somewhat worried about the headaches caused by interop. While this particular branch of the UI won't require much interop with the legacy C++ codebase, I can forsee this becoming an issue in the future.
The alternative is just to continue with MFC, but try and take advantage of the new feature pack that shipped with VS2008. This I guess is the easiest option, but I worry about longevity and not taking advantage of the goodness that is .net...
So, which do I pick? We're a small team so my recommendation will quite probably be accepted as a future direction for our development - I want to get it right.
Is MFC dead? Is C#/Winforms the way forward? Is there anything else I'm totally missing? Help greatly appreciated!
I'm a developer on an app that has a ton of legacy MFC code, and we have all of your same concerns. A big driver for our strategy was to eliminate as much risk and uncertainty as we could, which meant avoiding The Big Rewrite. As we all know, TBR fails most of the time. So we chose an incremental approach that allows us to preserve modules that won't be changing in the current release, writing new features managed, andporting features that are getting enhancements to managed.
You can do this several ways:
Host WPF content on your MFC views (see here)
For MFC MDI apps, create a new WinForms framework and host your MFC MDI views (see here)
Host WinForms user controls in MFC Dialogs and Views (see here)
The problem with adopting WPF (option 1) is that it will require you to rewrite all of your UI at once, otherwise it'll look pretty schizophrenic.
The second approach looks viable but very complicated.
The third approach is the one we selected and it's been working very well. It allows you to selectively refresh areas of your app while maintaining overall consistency and not touching things that aren't broken.
The Visual C++ 2008 Feature Pack looks interesting, I haven't played with it though. Seems like it might help with your issue of outdated look. If the "ribbon" would be too jarring for your users you could look at third-party MFC and/or WinForms control vendors.
My overall recommendation is that interop + incremental change is definitely preferable to sweeping changes.
After reading your follow-up, I can definitely confirm that the productivity gains of the framework vastly outweigh the investment in learning it. Nobody on our team had used C# at the start of this effort and now we all prefer it.
Depending on the application and the willingness of your customers to install .NET (not all of them are), I would definitely move to WinForms or WPF. Interop with C++ code is hugely simplified by refactoring non-UI code into class libraries using C++/CLI (as you've noted in your selection of tags).
The only issue with WPF is that it may be hard to maintain the current look-and-feel. Moving to WinForms can be done while maintaining the current look of your GUI. WPF uses such a different model that to attempt to keep the current layout would probably be futile and would definitely not be in the spirit of WPF. WPF also apparently has poor performance on pre-Vista machines when more than one WPF process is running.
My suggestion is to find out what your clients are using. If most have moved to Vista and your team is prepared to put in a lot of GUI work, I would say skip WinForms and move to WPF. Otherwise, definitely look seriously at WinForms. In either case, a class library in C++/CLI is the answer to your interop concerns.
You don't give a lot of detail on what your legacy code does or how it's structured. If you have certain performance criteria you might want to maintain some of your codebase in C++. You'll have an easier time doing interop with your old code if it is exposed in the right way - can you call into the existing codebase from C# today? Might be worth thinking about a project to get this structure right.
On the point of WPF, you could argue that WinForms may be more appropriate. Moving to WinForms is a big step for you and your team. Perhaps they may be more comfortable with the move to WinForms? It's better documented, more experience in the market, and useful if you still need to support windows 2000 clients.
You might be interested in Extending MFC Applications with the .NET Framework
Something else to consider is C++/CLI, but I don't have experience with it.
Thank you all kindly for your responses, it's reassuring to see that generally the consensus follows my line of thinking. I am in the fortunate situation that our software also runs on our own custom hardware (for the broadcast industry) - so the choice of OS is really ours and is thrust upon our customers. Currently we're running XP/2000, but I can see a desire to move up to Vista soon.
However, we also need to maintain very fine control over GPU performance, which I guess automatically rules out WPF and hardware acceleration? I should have made that point in my original post - sorry. Perhaps it's possible to use two GPUs... but that's another question altogether...
The team doesn't have any significant C# experience and I'm no expert myself, but I think the overall long term benefits of a managed environment probably outweigh the time it'll take to get up to speed.
Looks like Winforms and C# have it for now.
Were you to look at moving to C# and therefore .NET, I would consider Windows Presentation Foundation rather than WinForms. WPF is the future of smart clients in .NET, and the skills you pick up you'll be able to reuse if you want to make browser-hosted Silverlight applications.
I concur with the WPF sentiment. Tag/XML based UI would seem to be a bit more portable than WinForms.
I guess too you have to consider your team, if there is not a lot of current C# skills, then that is a factor, but going forward the market for MFC developers is diminishing and C# is growing.
Maybe some kind of piecemeal approach would be possible? I have been involved with recoding legacy applications to C# quite a bit, and it always takes a lot longer than you would estimate, especially if you are keeping some legacy code, or your team isn't that conversant with C#.