MFC is a giant bundle of hateful hate. It should be purged from this world with extreme prejudice and suggesting using MFC on a new project should be considered a capital offence.

Can you tell my opinion on the subject? ;)



The productivity gains of switching from MFC to WinForms simply can't be measured. It is literally night and day. Hell, I would even take the overwhelmingly awful C++/CLI or Managed C++ or whatever it is called today, so that I would work with WinForms instead of MFC! I could probably create an entire app in the same period it would take just to get one window up and running. God I hate MFC. Truth told though, I am extremely impressed with WinForms. There are a few faults ( one partially addressed be (sic) partial classes ), in that getting good separation of logic from presentation can be a bit of a choir, but it is workable. This lacking is where WPF comes in handy. It is really geared towards MVC or MVVM and makes implementing either simple and cleaner than WinForms data binding. That said, WinForms is like a well worn shoe for me now, so I've resisted moving to WPF. Frankly WinForms is simply more my style.


So yeah, I very much recommend moving away from MFC. If you are willing to switch languages, C#/WinForms is an amazing combination, while C#/WPF is somewhat the future. ( WPF works with Metro, WinForms, im not so sure. Additionally its a variant of WPF used for WinPhone ). You will be faster, more productive, write safer and probably faster code in either technology than you will with MFC. This is even including the fact you may have no bloody clue what you are doing inititaly.


If I were to have to create a C++ tool, for whatever reason, I would probably go with Qt.

Hi All!

Since now we've used MFC for the development of our game editor.
Basically the Tool is linked with our graphics library (a WIN32 static library that cares about 3d rendering mostly).

I'm wondering if switching to .NEt or WPF could give us a major benefit in terms of productivity.
Creating properties window, forms and other object with MFC is time consuming so we're searching for better solutions. Also we're gonna need to create timeline form to control animation and similar controls.


I'll be happy to have some advice on the topic

Mauro

We use C# and it you are far faster writing code in that then C++, even if you have to occasionally write the tidbit of C++/CLI to make interop between the main game lib and the tools work. This way you don't have to redo the 3D rendering in C# again,.

MFC is a giant bundle of hateful hate. It should be purged from this world with extreme prejudice and suggesting using MFC on a new project should be considered a capital offence.

Can you tell my opinion on the subject? ;)



The productivity gains of switching from MFC to WinForms simply can't be measured. It is literally night and day. Hell, I would even take the overwhelmingly awful C++/CLI or Managed C++ or whatever it is called today, so that I would work with WinForms instead of MFC! I could probably create an entire app in the same period it would take just to get one window up and running. God I hate MFC. Truth told though, I am extremely impressed with WinForms. There are a few faults ( one partially addressed be (sic) partial classes ), in that getting good separation of logic from presentation can be a bit of a choir, but it is workable. This lacking is where WPF comes in handy. It is really geared towards MVC or MVVM and makes implementing either simple and cleaner than WinForms data binding. That said, WinForms is like a well worn shoe for me now, so I've resisted moving to WPF. Frankly WinForms is simply more my style.


So yeah, I very much recommend moving away from MFC. If you are willing to switch languages, C#/WinForms is an amazing combination, while C#/WPF is somewhat the future. ( WPF works with Metro, WinForms, im not so sure. Additionally its a variant of WPF used for WinPhone ). You will be faster, more productive, write safer and probably faster code in either technology than you will with MFC. This is even including the fact you may have no bloody clue what you are doing inititaly.


If I were to have to create a C++ tool, for whatever reason, I would probably go with Qt.

C++/CLI is beautiful for interop far better then the hated marshall object stuff and just importing functions from dlls into C#.

WPF isn't that bad the way you define the layout is more geared towards a designer being able to layout the screen without ever having to touch C# code. Winforms is all defined through a massive cs file which defines where controls are, WPF is an XAML(layout) file with an additional cs to do the code actions. The Metro interface is different from XAML and will significantly differ in the future as it will be more HTML5 based.

C++/CLI is beautiful for interop far better then the hated marshall object stuff and just importing functions from dlls into C#.

WPF isn't that bad the way you define the layout is more geared towards a designer being able to layout the screen without ever having to touch C# code. Winforms is all defined through a massive cs file which defines where controls are, WPF is an XAML(layout) file with an additional cs to do the code actions. The Metro interface is different from XAML and will significantly differ in the future as it will be more HTML5 based.

My experience was with the original Managed C++ and it was a cludgy awful mess of a language. I do believe the next revision made it a hell of a lot nicer. I do see how it could be useful for writing intermediary layers however.

I don't actually have a ton of WPF experience, havent needed to. I've looked at moving from WinForms to WPF a few times, but never found a reason to justify the learning curve and havent had the free time to invest in learning it. I was going to embark on a silverlight project ( which uses a subset of WPF and also uses XAML ), but MS through a giant batch of "iffy" on the future of silverlight.

That said, my impression of Metro was WPF was one of the native options? Either HTML5/JS, or WPF(XAML) were supported?

I actually recommended Qt earlier. If I embark upon another GUI c++ application, I will use Qt.

You can easily call Win32 methods from C++, although you will rarely have to, .NET is pretty comprehensive.

does .NET provide simple methods for mapping c++ object with properties controls?

[font=helvetica, arial, verdana, tahoma, sans-serif][color=#282828]

If you mean can you create and call C++ classes from C#, the answer is no. You either need to make a managed wrapper around your c++ class using C++/CLI or using a C wrapper via pInvoke. There are facilities

for calling COM code however.[/font]

Im fairly certain you could find a control like what you need, there are probably more .NET controls than any other programming interface, with the possible exception of ActiveX.

I actually recommended Qt earlier. If I embark upon another GUI c++ application, I will use Qt.

You can easily call Win32 methods from C++, although you will rarely have to, .NET is pretty comprehensive.

does .NET provide simple methods for mapping c++ object with properties controls?

[font=helvetica, arial, verdana, tahoma, sans-serif][color=#282828]

If you mean can you create and call C++ classes from C#, the answer is no. You either need to make a managed wrapper around your c++ class using C++/CLI or using a C wrapper via pInvoke. There are facilities

for calling COM code however.[/font]

Im fairly certain you could find a control like what you need, there are probably more .NET controls than any other programming interface, with the possible exception of ActiveX.

The wrapper is the nicer options as you can create those classes in your C# code, the backend C++ code is a bit fidely as you need to sometimes still marshell the values. The only ones I had to do it for so far was when passing down strings as .NET strings but even that might have changed now, I am use to having a codebase at work to help me with this.

You will have to build that control timeline yourself I would imagine.