Re: MFC future?

Tech-Archive recommends: Speed Up your PC by fixing your registry



Daniel James wrote:

> In article news:<uqFbguCAGHA.3804@xxxxxxxxxxxxxxxxxxxx>, Mike
> Goldweber wrote:
> > So, what is the best way to produce dialog based apps using a C++
> > language?


> I write the GUI code using MFC, but I write the back-end code
> using standard C++ (with nothing Microsoft-specific) so it is easy to
> port to other systems. It is good design to make a clear separation
> between application logic and user interface code, and this practice
> enforces that.
It was late into my last position when I was introduced to the
Model-View-Controller architecture. Since being exposed to this, there
hasn't been any going back (except on really small utility apps). In
my new job, we do most of the computing behind the scenes, far away
from the user interface. It makes so much more sense.


>
> > My last job used Borland Builder to produce dialogs, and
> > that was great fun.
>
> Borland's C++ Builder and Delphi tools make prototyping a GUI using
> the supplied VCL components very quick and painless, ...but introduce
> unwanted relationships
> between application logic and GUI code and can be a source of
> unnecessary complexity in larger apps.

I agree with you on this issue. This was my experience with Borland
too.

> Overall I find MFC at least as productive.
Alright, so once I get familiar with the API, it sounds like I should
be fine.


> It depends what you want to do/are called upon to do. MFC is still
> Microsoft's best and only tool for programming native-code C++
> applications for Windows.

This is what I needed to know!! My boss writes his GUIs using the
CFormView as well.



> If you want to write managed .NET applications (rather than native
> code) you can still use C++ (especially if you're using VS2005) but
> you will probably use Windows Forms instead of MFC. There are reasons
> to want to use Forms, and reasons not to.

I'll have to make it a point to get familiar with this as well. It
never hurts to be familiar with too many tools.

> If you want to target non-windows systems such as linux or the Mac
> you shouldn't use MFC, but should look instead at one of the
> cross-platform toolkits such as Qt (commercial) or wxWidgets (Open
> Source). wxWidgets also targets Windows CE (or whatever it's called
> today) which MFC doesn't.
This is good to know. Thank you for mentioning these.


> MFC is one of the tools provided in VS 2003, so your company's choice
> doesn't restrict you (though, as I said, many of us feel that the VC6
> IDE was easier to use).

We are restricted to using .Net 2003, but I'm already seeing some
advantages over VC6. For example, I've been doing some database work,
and installation projects. This IDE supports both efforts! I was
surprised to be able to open up and build my installshield project from
Visual Studio.


Daniel, thank you very much for taking the time to explain this to me.
I really appreciate your help.

Sincerely,
Mike
.

Relevant Pages

  • Re: Help with text adventure
    ... You can also just write a console app with printf and getline, ... Is there a way to make a Win32 console application? ... Since you don't want or need MFC, ... windowing process of Windows, like it was behind any Windows program. ...
    (microsoft.public.win32.programmer.gdi)
  • Re: Learning process
    ... If you use wxWindows, the same code can be used for ANY ... I've said is that using wxWindows massively increases your userbase ... wxWindows, it would have a *potential* userbase of Windows, Mac <OSX, OS ... you're massively increasing the userbase which you 100% won't do using MFC. ...
    (alt.comp.lang.learn.c-cpp)
  • Re: Report from MVP Summit
    ... Win2K being phased out, and WinXP SP2 and Vista the only OS's we have to worry about, assuming things like the .NET Framework 3.0 being installed won't be out of the question, so we are now entering the sweet spot for .NET, much like Windows 3.0 marked the start of the sweet spot of Windows. ... the time to start switching is now (or at least start integrating some parts of the .NET framework into existing apps using C++/CLI). ... MFC is no longer meant to be the best way to develop Windows apps that are not huge. ... I'm guessing a good part of Office 2007 and Vista are still native so I'd guess Microsoft is still in that boat as well. ...
    (microsoft.public.vc.mfc)
  • Re: Closing modeless dialogs
    ... it isn't MFC that imposes most of these restrictions. ... It's the raw Windows API. ... THe MFC designers basically said "Since these things can't be done safely anyway, ... That is the core reason why you are using a worker thread instead of ...
    (microsoft.public.vc.mfc)
  • Fishy Behavior when using Managed code in Unmanaged environment
    ... We have an MFC application that is compiled under VS 2003 (its a pure ... AND THEN we found this article on MSDN "Windows Forms and Unmanaged ... When you open a Windows Form from a COM client application, ... Is this message pump incompatibility the real reason for our keyboard ...
    (microsoft.public.dotnet.framework.interop)