Re: Report from MVP Summit
"Tom Serface" <tom.nospam@camaswood.com> wrote in message
news:OJitt23aHHA.4140@TK2MSFTNGP06.phx.gbl...
So it improves the programmer's productivity, perhaps, but not necessarily
the programmer's program.
Yes, I think with a RAD based solution that uses components, it is
inevitable you give up ultimate flexibility and do it the component's way
because it's so easy, and since source code is not provided as much as it is
with MFC controls, it's harder to modify. Also, the .NET programmer works
with much higher level things like component properties and never dives into
Windows messages. There is no such thing as PreTranslateMessage() as far as
I know. ;)
It does make sense to keep at least a weather eye on all of the
technologies. One thing that bugs me is that everyone I meet (even
developers) seems to equate ".NET" with "C#". The C++ group needs to do a
better job of selling C++ as a first class .NET language. However, it
sounds like they may be focusing on native again and I can't argue much
with that. Regardless of how good .NET gets, there will always be a need
for native (at least for the forseeable future). We want to use the right
tool for the job regardless.
Besides being the right time to get into .NET now due to Vista essentially
replacing Win2K and what was left of Win9x/ME, it is a once in a lifetime
chance for us crufty C++ programmers to dive into .NET with the language we
love. WinForms is still a great UI platform, and C++/CLI is a first class
way to program WinForms. This won't last when Orcas comes out later this
year and causes XAML and WPF to be the focus. C++/CLI won't interop with
XAML. So start diddling with WinForms now in C++/CLI, before even this
becomes obsolete.
C++/CLI will still be a way of harnassing .NET subsystems in MFC programs,
but you wouldn't want to start a new .NET program using C++/CLI when WPF
takes hold.
Yeah, there hasn't been much "new" coming out for MFC for free, but some
of the guys who make money at it (like Ultimate Toolbox, and Xtreme
Toolkit, etc.) are getting really good and, for the price, you get a ton
of functionality.
Ultimate Toolbox is essentially dead. The last update just compiled with
VC2005. Not sure about XTreme, but basically MFC controls has become a
niche market.
Of course, there are also some dynamite .NET libraries. I would imagine
they are easier to write and, of course, work as assemblies for any of the
.NET syntaxes.
Yes, the thing that bugs me is it is standard not to ship source code. But
the catalog of .NET components is so large, the choice is clear.
Agreed. Or, when I really need to focus on performance on a user's desktop
that may not be a multi-processor super computer. I'm guessing a good
part of Office 2007 and Vista are still native (although I don't know any
particulars) so I'd guess Microsoft is still in that boat as well.
I would guess the reason they are still native is not for performance
reasons. It is because they have millions of lines of source code they
aren't willing to toss.
There are a lot of people who know MFC so it does still have some
momentum, but it really needs a lot of spiffing up to stay in the running.
I'm not sure what Microsoft intends to do with it, but I don't get the
impression that much of the "spiffing" has to do with UI.
I don't either.
There is a version of WPF called WPF/E (the /E is "everywhere) which I
believe is callable from native. Not sure about this.
That would be interesting...
This is discussed in those forums.microsoft.com/msdn thing.
-- David