Re: Report from MVP Summit

"VCPP" <no_vcpp_spam@xxxxxxxxxxxxx> wrote in message
news:Pf_Lh.86$u03.41@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx

Your main points from the video & views are very well articulated and
useful.

I am still not convinced if C#/.Net/MC++ give the flexibility, speed and
power to develop real world applications.

Thank you! For sure, .NET is not as flexible or as fast as native, but
depending on what you are doing, it is more powerful in that simple things
are truly simple, which leaves more time to develop more real world depth.
I think with Win9x/ME thankfully not even in the rear view mirror anymore,
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 (first mass deployed protected mode Windows
broke the 640 KB barrier and GP faults replaced random memory overwrites
that hung the entire PC) marked the start of the sweet spot of Windows. And
the trajectory moving forward will make this even more so. So, the time to
start switching is now (or at least start integrating some parts of the .NET
framework into existing apps using C++/CLI).


But MFC is always left behind in UI by MS.
I wish WPF and other new stuff is easily usable
with MFC and native code.


It's not just Microsoft that is leaving MFC but 3rd parties like component
developers and sites like CodeProject. There are far more UI controls for
..NET than for MFC now.

Like them, I certainly am not emboldened to stay in native if the main focus
of C++ is to have more tools to grok millions lines of code (useless to me),
increase standard conformance (useless to me), or to perpetuate hopelessly
complex libraries like STL (useless to me). MFC is no longer meant to be
the best way to develop Windows apps that are not huge (and pre-existing).
I see no reason to stay in C++ except if you have entrenched legacy code,
and lots of it.

OTOH, native code continues to enjoy performance and predictability, a
mature framework that is a real framework (i.e. has things like
document/view and not just a RAD canvas), a much better redist story, and
better resource localization. The question is, what will it be like in 5
years? Will C# and .NET get these features, or will C++ get the features of
..NET (like properties, delegates, clean syntax, etc.) It's clear the
managed camp are getting the lion's share of resources at Microsoft and are
making the most gains. I'm betting C# and .NET will pick up its missing
pieces faster than native will.

I still plan to write lots of native code involving things like hooks. But
I can't see where MFC offers any advantage for UI's.

There is a version of WPF called WPF/E (the /E is "everywhere) which I
believe is callable from native. Not sure about this.

-- David


.

Relevant Pages

  • Re: Future of MFC?
    ... for it to be easy to port Win16 API code to the new framework, ... Yes, you are right, that was one of the prime benefits of using MFC. ... compared to the Ribbon libraries available for .NET. ...
    (microsoft.public.vc.mfc)
  • Re: responding to user defined message from other applications
    ... Basically I need to have inter process communication, between a native MFC applicationa nd my C# program. ... Basically it works something like this, the MFC application is asctual a keyboard hook which translate keyboard combinations into special codes. ... The keyboard in this case is actual a USB remote control which generates keyboard combinations in the range of F13 to F24, and VK keys of SHIFT and CTRL. ... I don't know if IPCChannel in .NET 2 can be used on native code, ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: Command Pattern used in Frameworks
    ... where I'm also using MFC as the window manager framework. ... >a problem in interfacing one of the Command classes which changes the ... active document when the Command::execute message is sent. ...
    (comp.object)
  • Re: Single Document MDI-like interface questions
    ... MFC framework; this is not a justification for throwing it out! ... with the "batch view" as the only view, instead of all seven views you mention. ... As far as changing the toolbar, the first thing I would do is spend 30 seconds looking at ...
    (microsoft.public.vc.mfc)
  • Re: Windows Handle Map problem using COleControl and COleControlModule.
    ... we get an assert while attempting to run an MFC SDI app. ... I'm thinking this should get called for us by the framework, ...
    (microsoft.public.vc.mfc)