Re: My Review of MFC Beta

Well....after reviewing the MFC beta here is my opinion, for any one
who cares.

As every one knows, First of all this is not a MS native library. Some
third party library being decorated in MFC dress. Given that there
should ideally be a lot of color and convenience for the customers -
but my expectations were proved to be too optimistic. Here is why.

1. Most of this MFC beta covers what most people consider as just
"skin deep", if you know what I mean. If you remove the "theme" part -
the new enterprise controls introduced to MFC are the Dockers and the
property grid.

2. The "theme"/coloring/window style/visualization/ribbon, you name
it, is just a "painting effect" and not the original ribbon code of MS
Office. Given that, the prime question posed by many is why MS should
release a library that "mimics" the Office theme when they could port
the Office theme code to MFC and release it. Well I do not want to
talk about it - may be some licensing issues.

3. Since the theme portion is a "mimic" effect, can the user define
and create new themes with this so called Visualization Manager of MFC
beta? Nope !! You only get few "hard coded" themes - and like a big
teddy bear you have to select only among those four or five themes.
You cannot extend or override the predefined themes - at least I could
not find any provision for that in the code. And who really cares
about that weird Ribbon menus? What extra enterprise functionality
your customers would gain if you modify your tool bar to look like a
huge horizontal bar with extra large icons?

4. Coming to Source code, well...its a poor job too. Take a look at
any of the MFC beta new controls' source code and you would know what
I am talking about. The first prominent thing you can find is the
abundant misuse of "friend class" feature, followed by the next misuse
of "public data members". Not to mention about the global data
structures without a namespace or accessor functions.

5. As for the controls themselves, are they efficient? Well...I am not
sure - at least I was not impressed. May be I was wrong with this one
- but many times I came across unnecessary flickering with controls
when resized or re-layed out. May be there are functions inside that
we can override to optimize this - but I could not easily find them.

6. And are the controls extensible? Well, take a look at the property
gird - it has hard coded property editors for spin control, combo box.
Beyond that you cannot have your own in-place editors, such as check
boxes (for true/false) or slider control (for integers). Nor could I
find much support for extending the stock editors !!

7. The BCGSoft website has offered samples demonstrating the use of
few Grid controls such as report grid and multi-column tree view
controls etc... But I could not find any Grid control at all inside
the MFC beta !! Wondering if MFC beta is kind of "trial" version of
BCGSoft control libray, where if you like the MFC then you should go
and buy the full BCG Soft Control bar library.

All in all - the only real useful feature I can find in this version
(for enterprise level software) is - the docking ability for windows.
Beyond that the controls do not stand upto the level of MFC, nor the
code does.

Now having cribbed enough about this - lets put few points that could
make the VC++ robust. Lets think about What we really want from VC++.

The answer is simple: Lets have VC++ give all that the .Net is
providing to its developers. In otherwords,

1. We need the ability to generate, compile and build VC++/Win32/COM
dlls on the fly. We have been using VC++ compiler for so many years,
they never had the thought of making it re-usable API or component,
where as the .Net had this feature built in right from the startup.
  Why dont we have our cl.exe (and all other apps that are
responsible for compiling and generating the dlls) exposed as API?
Note that the major power .net has is because of its meta data and its
usage in reflection. We DO have metadata for native dlls too - in the
form of type-libraries for COM. But we are limited in our reflection
ability - we cannot dynamically create a COM dll in memory and load
its types from another App. We NEED this ability.
  This could bring a huge leap for VC++ developers. After all, today
they talk about ASP.Net with code behind .net assemblies. If those
bloated .net assemblies can bring ASP.net so much power, then imagine
how much power c++ native dlls could bring to the web applications.

2. We need all the latest controls the .Net is offering to its
developers: Right from the layout panels to the Property Gird UI
editors, Form design surfaces, Tray Icon notifiers, Visual Studio
debug visualizers...all accessible as WTL controls or MFC/Win32
controls. (Note that once we have the ability to generate C++ dlls on
the fly this should become possible and easy.)
   We need all the sleek looking Grid controls, report controls, mult-
column tree controls, property grid controls, HTML surface controls
(to bring the effect of styles/themes to our native applications, just
like those website styles/themes) ...

3. More importantly - stop pushing managed C++. This alone could be a
very big boon for all of us. Give us native XML parsers and do not
deprecate the SOAP tool kit.

These should be enough for now.

PS: These are my personal opinions. You may or may not agree with them.