Re: Future of MFC?

Tech-Archive recommends: Repair Windows Errors & Optimize Windows Performance

In article news:<_eSIi.8289$JD.3615@xxxxxxxxxxxxxxxxxxxxxxxxxx>, David
Ching wrote:
No Daniel, there is no way any enhancements to MFC can begin to
approach the ease and sophistication of the component model offered
by .NET.

Of course they can. Whether they will or not is entirely another
question.

For one thing, the design-time designers [in .NET] allow you to
setup the control in the resource editor with no coding whatsoever.

If I correctly understand the point you're making ... that's a feature of
the way the control is written rather than of the language or framework
that's targeted by the designer. MFC could have high-level designer tools
that lots of things automagically, but .NET does have some advantage over
native, here, because of the type information that a .NET component
publishes along with its callable interfaces to make life easier for the
designer. It'd be quite feasible to put that sort of thing into (say) an
XML resource linked into any native DLL, and to write a high-level
designed that targeted MFC (or any other native framework, for that
matter). All that's needed is the will to make the tools for native
development better ... better than they are, and better than the .NET
stuff.

Not to mention the philosophy difference that MFC developers don't
mind getting their hands dirty to use the MFC controls, and little
effort is made to shield them from the low level details.

Don't imagine that we MFC developers like getting our hands dirty when we
don't have to ... if we had tools to etch-a-sketch a GUI and keep our
hands clean we'd use them, just like .NET developers do. The difference
is that we would also know how to things that the tools didn't automate,
and that we'd be able to look under the covers and fix it if anything
went wrong. The "philosophical difference" here is within MS, where they
seem to think that because we do know how to work at the low level we
actually like to do so ... that's not true, we can be as lazy as the next
developer when we have tools that actually work and that do a job worth
doing.

Just because .NET has better tools today, that doesn't mean that is has
to be that way.

Cheers,
Daniel.


.

Relevant Pages

  • Re: In need of .NET advocacy
    ... Microsoft ASP.NET URI Canonicalization Unauthorized Web Access ... Vulnerability ... because the MFC classes are created in the none-Object way of thinking. ... the market of .NET developers will get a big boost. ...
    (microsoft.public.dotnet.general)
  • Re: What I saw at MS Launch
    ... > developers this frightened away. ... That's a potential weakness that Borland could ... Binding a grid to a collection is now REALLY easy. ... WinForms designer, and have it just display an error message. ...
    (borland.public.delphi.non-technical)
  • Re: Compiler Migration
    ... I must continue to support executables what run on DOS/Windows ... apps, doesn't support MFC, supports .NET, STL and the native CRT. ... I don't remember what optimization choices it has but it doesn't ... A far cry from Balmer's "Developers, ...
    (microsoft.public.vc.mfc)
  • Re: Compiler Migration
    ... I must continue to support executables what run on DOS/Windows ... apps, doesn't support MFC, supports .NET, STL and the native CRT. ... I don't remember what optimization choices it has but it doesn't ... A far cry from Balmer's "Developers, ...
    (microsoft.public.vc.mfc)
  • Re: Thinking Clearly
    ... known as "Data Dude" which integrates into Visual Studio 2005 Professional ... new compiler but there are new compiler for WinFX. ... The Expression Interactive Designer aka Sparkle will be a commercial product ... but for some developers this adoption may also have a positive ...
    (borland.public.delphi.non-technical)