Re: My Review of MFC Beta
<NightHawkMailBox@googlemail.com> wrote in message
news:2f9125f7-04b8-42cc-95c6-17a20101d65c@i72g2000hsd.googlegroups.com...
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.
Do you not find this extra benefit attractive? Several months ago, I used a
property grid from CodeProject but it would have been more convenient if
this had been available to me, as it will be now.
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.
Well, to be blunt, so what? What do we care whether it is the same code
that is running in Office 2007 or not? Actually, I'm glad it's not the
same, as the first one is bound to be hacked up and not well factored; first
attempts often are. By completely rewriting the API to achieve the same
goal, I'm sure it is much cleaner than the original.
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.
Surely if they support several hard-coded themes, how hard is it to create
another hard-coded theme if you have access to the source code? I mean, if
they support several themes already, it must be somewhat generic, right?
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?
If you have to ask, then you would not use the ribbon anyway. Users will
determine the success of the ribbon; from what I've seen, they are evenly
split between loving it and not liking it. You can't argue that a ribbon
makes your app look modern, which depending on your audience, is the entire
battle (productivity is not a concern to some people).
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.
That's too bad; Microsoft started this effort months ago, I would have hoped
they would have cleaned up the code during that time. No doubt with the
proliferation of 3rd party frameworks, the code in the core MFC is (or was)
much better than the what is in the 3rd party frameworks.
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.
Yup, the performance of BCGSoft is sadly lacking. That's why I chose
CodeJock instead. Again, I would have thought MS would have spent all
these months improving it to be at least as good as CodeJock, but it doesn't
sound like they did.
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 !!
Same as for the ribbon themes - they must support adding additional editor
controls in the same manner as they created the original ones.
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.
Yes, Microsoft has clearly stated they did not license the entire library,
and if you want the whole thing you need to buy the BCGSoft separately.
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.
Heh, we sing the same song, you and I. But I've stopped singing it. The
reason is there's no way Microsoft will invest in bringing .NET features
into native C++, as native C++ is a shrinking market and they really want
Windows apps to be managed anyway, as security is better.
I really appreciate your time in writing these opinions. I've referenced
them on a private VC++ newsgroup for MVP's, so the dev team at MS can see
it.
-- David