Considering move from MFC/C++ to Winforms/C# ??? looking for advice
-
Hi. I'm writing a desktop application. I have 6+ years of C++ / MFC, so I started off writing it in MFC/C++. I'm considering switching it to Winforms & C#, as I can see I might have a future need for mobile/web development, and I don't want to lock into an older technology that Microsoft doesn't seem too keen on enhancing in the future (i.e. MFC) If I do move the app, I'd take the full plunge and re-write the whole dang thing in C#, so I'm not concerned about any interop (etc) issues. I've read a C# book, and the language seems straightforward for me, given my C++ experience, so I'm not worried about the language itself. I'd like to hear some advice on: 1) WinForms/C# - how is the UI programming experience (I'd especially like to hear, if you have extensive MFC experience)? e.g. How does using purchased components, or writing custom controls compare with MFC? I've read "you must be on crack to even consider MFC in 2005" in a few message boards, but I've yet to be convinced - would you agree with this? 2) WinForms/C# - what do you think the prospects are with regard to the new Vista UI (i.e. is XAML going to kill off support for WinForms)? Should I just stick with MFC for now, and then move it over to XAML in a number of years ??? 3) If I do go for it, I plan to buy a lot of the UI components - can anyone recommend some UI suites (e.g. Infragistics). I'm looking for: a good extensible "grid", VS2005 style docking windows, a VS2003+ property grid, and a report control. Any advice would be very much appreciated... Warren Stevens
-
Hi. I'm writing a desktop application. I have 6+ years of C++ / MFC, so I started off writing it in MFC/C++. I'm considering switching it to Winforms & C#, as I can see I might have a future need for mobile/web development, and I don't want to lock into an older technology that Microsoft doesn't seem too keen on enhancing in the future (i.e. MFC) If I do move the app, I'd take the full plunge and re-write the whole dang thing in C#, so I'm not concerned about any interop (etc) issues. I've read a C# book, and the language seems straightforward for me, given my C++ experience, so I'm not worried about the language itself. I'd like to hear some advice on: 1) WinForms/C# - how is the UI programming experience (I'd especially like to hear, if you have extensive MFC experience)? e.g. How does using purchased components, or writing custom controls compare with MFC? I've read "you must be on crack to even consider MFC in 2005" in a few message boards, but I've yet to be convinced - would you agree with this? 2) WinForms/C# - what do you think the prospects are with regard to the new Vista UI (i.e. is XAML going to kill off support for WinForms)? Should I just stick with MFC for now, and then move it over to XAML in a number of years ??? 3) If I do go for it, I plan to buy a lot of the UI components - can anyone recommend some UI suites (e.g. Infragistics). I'm looking for: a good extensible "grid", VS2005 style docking windows, a VS2003+ property grid, and a report control. Any advice would be very much appreciated... Warren Stevens
1. I still think MFC is a viable platform, but Winforms is definately easier, and at least as easy to write custom controls for. At the end of the day, you can access the underlying message loop, you can call any C++ API via interop, so I doubt there's anything you can't do. 2. XAML is not going to kill Winforms IMO. For starters, you can only ship WinFX to XP, 2003 or Vista. Until there is no need to support W98 or W2000, WinFX seems to me to be a sleeper technology. 3. The grid in Winforms is fine, no need to buy. I don't know of any control libraries, because I've never used one. If you're going to switch to C#, can you wait a few weeks and buy VS2005 ? C# 2.0 is awesome. Christian Graus - Microsoft MVP - C++
-
Hi. I'm writing a desktop application. I have 6+ years of C++ / MFC, so I started off writing it in MFC/C++. I'm considering switching it to Winforms & C#, as I can see I might have a future need for mobile/web development, and I don't want to lock into an older technology that Microsoft doesn't seem too keen on enhancing in the future (i.e. MFC) If I do move the app, I'd take the full plunge and re-write the whole dang thing in C#, so I'm not concerned about any interop (etc) issues. I've read a C# book, and the language seems straightforward for me, given my C++ experience, so I'm not worried about the language itself. I'd like to hear some advice on: 1) WinForms/C# - how is the UI programming experience (I'd especially like to hear, if you have extensive MFC experience)? e.g. How does using purchased components, or writing custom controls compare with MFC? I've read "you must be on crack to even consider MFC in 2005" in a few message boards, but I've yet to be convinced - would you agree with this? 2) WinForms/C# - what do you think the prospects are with regard to the new Vista UI (i.e. is XAML going to kill off support for WinForms)? Should I just stick with MFC for now, and then move it over to XAML in a number of years ??? 3) If I do go for it, I plan to buy a lot of the UI components - can anyone recommend some UI suites (e.g. Infragistics). I'm looking for: a good extensible "grid", VS2005 style docking windows, a VS2003+ property grid, and a report control. Any advice would be very much appreciated... Warren Stevens
-
Hi. I'm writing a desktop application. I have 6+ years of C++ / MFC, so I started off writing it in MFC/C++. I'm considering switching it to Winforms & C#, as I can see I might have a future need for mobile/web development, and I don't want to lock into an older technology that Microsoft doesn't seem too keen on enhancing in the future (i.e. MFC) If I do move the app, I'd take the full plunge and re-write the whole dang thing in C#, so I'm not concerned about any interop (etc) issues. I've read a C# book, and the language seems straightforward for me, given my C++ experience, so I'm not worried about the language itself. I'd like to hear some advice on: 1) WinForms/C# - how is the UI programming experience (I'd especially like to hear, if you have extensive MFC experience)? e.g. How does using purchased components, or writing custom controls compare with MFC? I've read "you must be on crack to even consider MFC in 2005" in a few message boards, but I've yet to be convinced - would you agree with this? 2) WinForms/C# - what do you think the prospects are with regard to the new Vista UI (i.e. is XAML going to kill off support for WinForms)? Should I just stick with MFC for now, and then move it over to XAML in a number of years ??? 3) If I do go for it, I plan to buy a lot of the UI components - can anyone recommend some UI suites (e.g. Infragistics). I'm looking for: a good extensible "grid", VS2005 style docking windows, a VS2003+ property grid, and a report control. Any advice would be very much appreciated... Warren Stevens
Hi, Warren! Sorry to bring up this 6 month old post :), but about the time of your post I was working on certain ...Prop application (you might recall that old project). It is a desktop app and was written initially in .NET Managed C++ by someone else. My task was to "fix it up" and I had two month (with lots of overtime) to do it. Well, it wasn't well written to begin with, so I ended up almost rewriting the whole thing. The experience was very unpleasant. 1. Working with WinForms resources VS2003 is horrible. And why aren't the sizes and coordinates relative like with MFC/Win32? Absolute pixel coordinates is a horrible idea! I pulled lots of hair trying to get some of the controls to look properly on different monitor resolution. 2. With MFC you got all the source code so you can get down and dirty and customize some controls to behave and look just the way you want it. Not with .NET controls! Customizing certain controls was also a great pain. 3. If you use Interop, browser control, and third party controls (which you would in most professional desktop apps) you end up with gazillion dlls that have to be shipped with your executable. 4. Cannot run .NET app off the network. There are workarounds, but they are so complicated and all have to be done on client side by the person installing your app. Just reading these workarounds I got a feeling that you ahve to be an IT pro to do it. 5. Code protection. Basically you are giving awya your source code with every app that you ship to your customer. Sure you can try obfuscating, but that doesn't solve the problem 100%. 6. And why did they have to use exceptions for any kind of error mechanism? What's wrong with returning true/false and maybe add another way of retrieving details of error at my own peril? All these exceptions drove me nuts! Sometimes I don't want to be concerned if something very insignicant fails! Maybe I just check for a final result and that's good enough. But not in .NET - you can't leave anything unchecked! You have to add ugly try/catch block to every .NET framework call if you want to make sure that your app doesn't pop-up a very confusing message box to your end user. These are just a few issues that come to my memory. I still recall that experience as big and very long nightmare. I like MFC and I'm still sticking to it, until an app written in it just won't run on some new version of Windows...
-
Hi, Warren! Sorry to bring up this 6 month old post :), but about the time of your post I was working on certain ...Prop application (you might recall that old project). It is a desktop app and was written initially in .NET Managed C++ by someone else. My task was to "fix it up" and I had two month (with lots of overtime) to do it. Well, it wasn't well written to begin with, so I ended up almost rewriting the whole thing. The experience was very unpleasant. 1. Working with WinForms resources VS2003 is horrible. And why aren't the sizes and coordinates relative like with MFC/Win32? Absolute pixel coordinates is a horrible idea! I pulled lots of hair trying to get some of the controls to look properly on different monitor resolution. 2. With MFC you got all the source code so you can get down and dirty and customize some controls to behave and look just the way you want it. Not with .NET controls! Customizing certain controls was also a great pain. 3. If you use Interop, browser control, and third party controls (which you would in most professional desktop apps) you end up with gazillion dlls that have to be shipped with your executable. 4. Cannot run .NET app off the network. There are workarounds, but they are so complicated and all have to be done on client side by the person installing your app. Just reading these workarounds I got a feeling that you ahve to be an IT pro to do it. 5. Code protection. Basically you are giving awya your source code with every app that you ship to your customer. Sure you can try obfuscating, but that doesn't solve the problem 100%. 6. And why did they have to use exceptions for any kind of error mechanism? What's wrong with returning true/false and maybe add another way of retrieving details of error at my own peril? All these exceptions drove me nuts! Sometimes I don't want to be concerned if something very insignicant fails! Maybe I just check for a final result and that's good enough. But not in .NET - you can't leave anything unchecked! You have to add ugly try/catch block to every .NET framework call if you want to make sure that your app doesn't pop-up a very confusing message box to your end user. These are just a few issues that come to my memory. I still recall that experience as big and very long nightmare. I like MFC and I'm still sticking to it, until an app written in it just won't run on some new version of Windows...
Hi Damir.
Damir Valiulin wrote:
Sorry to bring up this 6 month old post
I don't mind discussing a 6 month old post, mainly because I can't say I really came to a definitive conclusion, and I feel the question remains to be answered.
Damir Valiulin wrote:
I was working on certain ...Prop application...My task was to "fix it up" and I had two month (with lots of overtime) to do it.
I'd have to say I'm one of the few people who can really appreciate that...and it must have sucked. I hope you at least got a good bonus for your suffering :-D
Damir Valiulin wrote:
I ended up almost rewriting the whole thing.
That seems to be a recurring theme. Unfortunately (and this seems to be common to almost all programmers) once someone sees an application that has 80% of the required features, it's very hard to convince them that the project should be started from scratch because the code is a steaming pile of .... X| If you want to build commercial-quality software that will last for many versions/years, it simply cannot be built from a foundation that was written by a student. Period. :sigh: 1) Yeah, absolute pixels are right out of the 1980's !?! XAML should fix all of that - assuming you don"t have to ship anything before 2009 ;P 5) I can't say I'm totally up on the subject, but I don't see how decent code protection (e.g. hardlocking) could ever be done in a byte-code system like .NET. From what I've seen, even obfuscated code is fairly readable when "disassembled". I don't think Microsoft is overly concerned about this, so I'm not sure if it will be solved any time soon. 6) I absolutely and totally agree with you on exceptions. They look great on a computer science chalkboard, but aside from file I/O, I would say exceptions are highly overrated for writing practical code. I think the main reason they're so popular these days is that it's great for framework authors (they just say "the caller will deal with it" and they're done), while sticking people like us with the hassle of catching all of their problems. And (finally), for the topic at hand... I considered C#/Winforms/etc quite thoroughly (I bought and read through a good number of books, and tried tons of sample code) and my opinion is: i) I found C# very elegant compared to C++ (e.g. properties, events), with the exception of not having destructors (whi