Re: MFC future?

Hi Joseph,

This is just another illustration of the mixed message MSFT is sending to
the community. Over the last few years they have managed to make C# look
"cool" and "productive" and MFC (and C++) look "dated" and "unhip". I don't
know if this is intentional or not (I suspect it's just one group doing a
better marketing job), but I can understand how some feel the need to
wonder. Even if MFC was never improved it is still a great tool for certain
types of applications, but I can certainly understand how people who invest
their time in a coding paradigm would want to feel like they are doing
something worth their while. These days we all, especially the younger
guys, want our resumes to say the right things.

I haven't seen any major commercial desktop applications (including those
from Microsoft) written in C#. That doesn't mean they don't exist, but I
have asked around a lot. However, for RAD programming for internal use C#
is sure easier to use to cobble together form or web based applications.

Bottom line: I agree with you. The whole .NET message is often very
confusing. In fact, I think it's misnamed. From what I can tell it doesn't
have so much to do with "The NET" or "A NET" as it does with trustworthy or
managed computing. Code security is a good idea and, frankly, I hope that
it pans out eventually, but it's not like it's a new idea or anything.
We've had Java and Pascal for some time. Microsoft may have the resources
to make the "pcode" idea work efficiently enough to actually make it fast
enough for prime time ... or the computers may just catch up with the power
needed to run these types of programs.

Until then, I say, use the best tool for the job you're doing. Every
project is different.

Tom

"Joseph M. Newcomer" <newcomer@xxxxxxxxxxxx> wrote in message
news:s1gvo1poel8vo55dn8d9k3bt001ub7o3c1@xxxxxxxxxx
> Omigod! Not Another Futhre Of MFC Question....!!!!
>
> It lives. It is supported. It does not appear to be going away any time
> soon.
>
> Note that ".NET" is *NOT* the opposite of "MFC", and I'm not sure how this
> interpretation
> ever got started. In fact, MFC is absoultely compatible with several
> varying
> interpretations of whatever ".NET" might mean to you. C# is *not* ".NET";
> C# is a
> programming language. It just happens to be more easily compatible with
> certain
> interpretations of .NET than MFC is (you have to do a little more work in
> MFC to meet the
> criteria). I'm not even sure what "learning .NET" even means! Do you
> mean certain kinds
> of component architecture, or something to do with manifests, or something
> to do with XML,
> or what? I have yet to figure out what ".NET" means, except I know a lot
> of pieces of
> technology that form the .NET infrastructure. Many are orthogonal to each
> other, and
> independent of the programming language used (C#, MFC, VB, Cobol, etc.)
> joe
>


.

Relevant Pages

  • BUG: Gdiplus::Image::FromStream() leaking references in Unmanaged C++ applications
    ... that this bug only exists in unmanaged C++ applications that are using ... to take advantage of GDI+ rendering technology). ... possible that this problem could be related to the nature of MFC ... addition to deleting the Image objects and ...
    (microsoft.public.win32.programmer.gdi)
  • Re: Is it advantageous to use .NET Framework DLLs in Access?
    ... applications to .Net applications in C# (this kinda reminds me how I had ... one thing the PHP/classic ASP can't do which .Net does is to create ... development of .Net - to simplify the big stuff). ... century) to create a multi-tiered system in MFC? ...
    (comp.databases.ms-access)
  • SysListView32 Content Scraping
    ... I have a program which grabs data from 3rd-party applications. ... My first problem is actually identifying the MFC Window. ... Builder just wrap around the internal Win32 control so the a handle ...
    (microsoft.public.win32.programmer.ui)
  • Re: Show Dialog from MFC Extension DLL
    ... and used by both MFC applications as well as non-MFC applications. ... I simplify things by exporting a non-MFC class that "represents" my dialog. ... file that has no MFC in it, so they aren't exposed to it (this is what allows ATL and console applications to use the DLL to show the dialog). ...
    (microsoft.public.vc.mfc)
  • Re: VC/MFC world status request
    ... MFC is also good for people who want to make "smaller" desktop applications that are easy to distribute. ... So far I don't think there is a way to statically link .NET applications. ... I think we will see C++/MFC getting new life as the platform of choice for native desktop applications or other applications that don't require managed code. ...
    (microsoft.public.vc.mfc)