My Review of MFC Beta
NightHaw...@googlemail.com
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.
Tom Serface
I think the new controls from BCGSoft are only the ribbon and skinning
controls. The skinning controls include the toolbar, menu, etc. The
treelist (report) grid is not included (I asked) and some other BCGSoft
controls like the date, editor, etc. are not included.
I think this will improve the average user's out of the box experience and
I'm glad Microsoft was willing to get the controls they did. Many people
have asked for this sort of functionality over the years. Perhaps they will
extend it as time goes on and requests for more tools comes in from users.
Tom
<NightHaw...@googlemail.com> wrote in message
news:2f9125f7-04b8-42cc...@i72g2000hsd.googlegroups.com...
David Ching
news:2f9125f7-04b8-42cc...@i72g2000hsd.googlegroups.com...
> 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.
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
Ajay Kalra
> 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.
>
Ditto.
---
Ajay
BobF
"Ajay Kalra" <ajay...@yahoo.com> wrote in message
news:230012A9-9AAD-4D59...@microsoft.com...
I've was one of those C++/MFC die-hards. A couple of months ago or so, I
started dabbling with C#/WPF GUIs. It's a night/day comparison - C#/WPF
being the day.
Instead of hoping for an MFC miracle, I'll be working towards a general
model for creating apps with a .Net GUI and a C++ backend for performance
sensitive processing.
I agree that the big drive from MS is to get everything into managed apps in
the near- and medium-term.
<crystal ball>
IMO, the long-term goal will be web apps as much as possible. .Net will
provide the platform security, web-centric applications will fight piracy
and simplify distribution.
Web-centric apps will also move the world to a subscription model instead of
the current purchase/support subscription model. Properly packaged by
marketing gurus, this will look like (and could very well be) a savings by
removing the one-time up front charge.
</crystal ball>
I think the recent MFC update makes it pretty clear that there won't be a
lot out there for MFC in the future.
Giovanni Dicanio
"BobF" <rNfOrS...@charter.net> ha scritto nel messaggio A couple of
> started dabbling with C#/WPF GUIs. It's a night/day comparison - C#/WPF
> being the day.
Yes, I also think that C#/WPF is great technology for presentation layer.
However, there are some reasons to still use MFC, like supporting and
evolving old code base (which works well, so why rewrite to C#?). Another
reason is the fact that - in general - MFC native apps tend to be faster
(and smaller) than managed ones, at least on current hardware (for example,
at startup, no need for JIT compiling is required, and no need to load the
.NET framework "monster").
And C++ is still a very important player in the game, for example, to use
multiplatform libraries (scientific libraries like Blitz++, several graphics
engines - also open-source, like Coin3D or OpenSceneGraph, etc.). And also
for some specific Windows-only stuff, like developing shell-extensions, I
think that C++ is the way to go.
BTW: I also would like to congratulate to the OP who started this thread:
his post is very interesting reading.
Giovanni
Ian Semmel
"BobF" <rNfOrS...@charter.net> wrote in message
news:O$uMeYdWI...@TK2MSFTNGP05.phx.gbl:
Yes, I agree with you. Once you get into C# and .net it sort of hooks
you and doing mfc stuff feels like you are stepping back.
Knowing both mfc and .net is a great advantage as native code systems
will be around for a long time (decades). It is easier to go mfc -> .net
than the other way around in my opinion.
Tom Serface
having options. The way things stand now I don't think a lot of people
would use C++ to do managed code. So, the only place it really shines is in
total native, or mixed mode. So, the C++ guys need to continue to improve
that experience to keep C++ in the game. I don't think it's going away any
time soon.
Tom
"Ian Semmel" <any...@rocketcomp.com.au> wrote in message
news:Ooa0LVgW...@TK2MSFTNGP03.phx.gbl...
BobF
G and Ian ... I should've been more clear on this last point. I was
referring to updates and new functionality when I said (typed) "there won't
be a lot out there for MFC in the future".
Of course there will be plenty of MFC-oriented work for a very, very long
time. I just don't believe there will be much evolution for MFC as a
technology.
Ajay Kalra
> I think the recent MFC update makes it pretty clear that there won't be a
> lot out there for MFC in the future.
It was clear to me many years ago. It made no sense for MSFT to invest any
resources in VC++. It still doesnt. MC++ was really not needed. CLI is good
but its usefulness is limited to current unmanged C++ environement, which by
definition would not want to use .Net.
---
Ajay
Ajay Kalra
Its a huge step back. And its not just the GUI part. As you traverse thru
the framework classes, things like threading, asynchronous constructs make
it very appealing. MFC provides an insignifant subset of the framework.
> Knowing both mfc and .net is a great advantage as native code systems will
> be around for a long time (decades). It is easier to go mfc -> .net than
> the other way around in my opinion.
I felt the same but its not true. Going from MFC, its easy to pick up UI
stuff but UI stuff alone is not enough. Its a new way and a much easier way
and it doesnt care about Win32 in general(I havent had to use PInvoke so
far).
---
Ajay
>
>
Ajay Kalra
"Tom Serface" <tom.n...@camaswood.com> wrote in message
news:A108B960-857A-483A...@microsoft.com...
>I think like so many things the application dictates the tools. It's nice
>having options. The way things stand now I don't think a lot of people
>would use C++ to do managed code.
That is the right decision.
>So, the only place it really shines is in total native, or mixed mode.
>So, the C++ guys need to continue to improve that experience to keep C++ in
>the game. I don't think it's going away any time soon.
>
It certainly wont go away but its that specilazed environment now where
developers are dwindling in C++.
---
Ajay
Ajay Kalra
Thats how I feel. Its just wasted resources in part of MSFT to even think
about it. Keep in mind MSFT has already retired WinForms in favor of WPF.
---
Ajay
Tom Serface
we're talking about many years before the functionality of .NET makes it
THAT much better than C++. The only thing that really makes .NET a little
better for me, in some cases, is the libraries that are included. There is
something to do just about everything. I also think the IDE (including
Intellisense) works better with C# code making the coding experience that
much nicer. However, I don't think C# desktop applications are easier than
MFC. Of course, I have a lot of MFC experience so that helps me be biased.
If I were starting a new desktop application today I'd have a difficult time
trying to figure out which paradigm to use. The new MFC controls that come
in the box might help, but typically the cost of these ltypes of libraries
is not a big barrier to purchase. I have a lot of time invested in using
MFC and some 3rd party libraries. I've been learning C# and .NET while
working on an ASP project so that environment is getting more familiar all
the time, but I still feel most at home doing MFC stuff. As long as there
are guys like us around MFC will still have life.
Tom
"Ajay Kalra" <ajay...@yahoo.com> wrote in message
news:444829B0-0628-4F04...@microsoft.com...
David Ching
> That could be true. It's hard to predict where it will go, but I think
> we're talking about many years before the functionality of .NET makes it
> THAT much better than C++. The only thing that really makes .NET a little
> better for me, in some cases, is the libraries that are included. There
> is something to do just about everything. I also think the IDE (including
> Intellisense) works better with C# code making the coding experience that
> much nicer. However, I don't think C# desktop applications are easier
> than MFC. Of course, I have a lot of MFC experience so that helps me be
> biased. If I were starting a new desktop application today I'd have a
> difficult time trying to figure out which paradigm to use. The new MFC
> controls that come in the box might help, but typically the cost of these
> ltypes of libraries is not a big barrier to purchase. I have a lot of
> time invested in using MFC and some 3rd party libraries. I've been
> learning C# and .NET while working on an ASP project so that environment
> is getting more familiar all the time, but I still feel most at home doing
> MFC stuff. As long as there are guys like us around MFC will still have
> life.
>
Have you done any WinForms or WPF? Much of the crud of ASP.NET is removed,
and it's a much more direct comparison to MFC. (ASP.NET is a hybrid between
C#, Javascript, ASP, CSS, HTML, and probably more, that much of the pain is
switching between them and confusing the great .NET stuff from the other web
crap).
-- David
Tom Serface
on the web. So, I've done a lot of web forms, but not many WinForms and
only WPF for the sake of playing around with it. Are you saying WinForms
can be run on the web? If so, I didn't know that.
Tom
"David Ching" <d...@remove-this.dcsoft.com> wrote in message
news:eb9lj.784$hI1...@nlpi061.nbdc.sbc.com...
David Ching
> The bulk of what I've done with .NET has been ASP.NET since it needs to
> run on the web. So, I've done a lot of web forms, but not many WinForms
> and only WPF for the sake of playing around with it. Are you saying
> WinForms can be run on the web? If so, I didn't know that.
>
No, WinForms can't run on the web. But to compare .NET to MFC, you really
should be doing a WinForms or WPF project, and not ASP.NET. ASP.NET, even
though it uses C# and has the full .NET framework available to you, still
has too much web stuff getting in the way to compare it with the ease of a
desktop app.
I believe Silverlight is MS's attempt to have a common framework for both
desktop and web development.
-- David
Ajay Kalra
*significantly* ahead in terms of development environment and features. MFC
is at least few years behind and will likely die the way it is. There is a
reason MFC hasnt had any significant change in last well.. decade. That
doesnt mean its not useful now but its long gone as a main platform for GUI
apps.
Keep in mind WinForms are now toast. WPF is the new choice.
>However, I don't think C# desktop applications are easier than MFC.
I disagree strongly that C# apps are difficult compared to MFC. MFC is at
least 4-10x difficult to master than WinForms. The fact that you are not
using C++ and C# instead alone justifies the benefit.
If microsoft came out with MFC in its current form for the first time in
2007, the product will never make it out of the door.
--
Ajay
"Tom Serface" <tom.n...@camaswood.com> wrote in message
news:F8DD856E-B460-4088...@microsoft.com...
Ajay Kalra
> The bulk of what I've done with .NET has been ASP.NET since it needs to
> run on the web. So, I've done a lot of web forms, but not many WinForms
> and only WPF for the sake of playing around with it. Are you saying
> WinForms can be run on the web? If so, I didn't know that.
>
I know nothing about ASP.Net nor do I care as its not what MFC is about.
ASP.Net did not replace MFC. It merely helped making web apps. You are not
using MFC to build ASP apps.
Proper comparison is WinForms and now WPF.
---
Ajay
Tom Serface
major project. I'm reticent to spend much time on it now that WPF is
becoming more interesting.
Tom
"David Ching" <d...@remove-this.dcsoft.com> wrote in message
news:mzblj.2586$nK5....@nlpi069.nbdc.sbc.com...
Tom Serface
over the years. There are likely a lot of people like me who have already
spent a lot of time learning MFC so the comparison is not fair (as if we
were starting from scratch). That gives MFC some momentum still. You are
right that the tools for using C# and WinForms seem more advanced in the
IDE. In fact, the biggest criticism everyone has about MFC is the loss of
the better tools we used to have to provide a common IDE that better
supports the other languages.
Tom
"Ajay Kalra" <ajay...@yahoo.com> wrote in message
news:591FD94B-7BE8-445B...@microsoft.com...
Tom Serface
been done in MFC. A previous version was done in MFC, and then in Perl, and
then Java, and now ASP.NET. I am impressed at how far we've come with tools
for developing web applications. Going from Perl to ASP.NET is like night
and day.
Tom
"Ajay Kalra" <ajay...@yahoo.com> wrote in message
news:OiFVKDKX...@TK2MSFTNGP04.phx.gbl...