But then, of course, you have already found out from your posts on other forums that this change
behavior came as part of the comctl32 v6, and not anything to do with a change in MFC. Unless, of
course, you indirectly blame MFC for using the v6 of the common controls when built for Unicode.
I find your claim amusing that derived classes should behave just like their base classes (CWnd,
instance), or it is a "bug". What's the point of deriving classes, if not to modify, enhance, or
"Joseph M. Newcomer" <newcomer@flounder.com> wrote in message
Actually, the point was that *some* of the classes do not support the expected methods
that a CWnd-derived class is expected to support. That's a definition of a 'bug'. "Not
working as designed" is a cop-out that says "we screwed up the design". That's a bug. It
is a design bug, but from the viewpoint of someone who needs the capability, it means it
does not do the job it is supposed to do.
For example, if I have the ability for decades to disable a group box to indicate that
none of the controls is enabled (think of the enable of the group box as the logical-OR of
the enable state of all the controls inside it), and some new release of a group box
doesn't gray out when I disable it, that's a bug. It doesn't matter that the control was
not designed to gray out; all previous versions of that control in history grayed out, and
if the current design does not do so (and it doesn't) then it has been broken.
A number of complaints about the new Feature Pack controls is that if you perform an
operation that is part of the CWnd class on them, they do not respond, or respond
inappropriately. This means the design of those controls is inconsistent with the design
of all other windows, and that is a bug.
Microsoft seems to love the "this behavior is by design" as a way of saying "tough. We
broke the design but we're not going to fix it". That is not a way of endearing yourself
to your developers/customers, and when the "new, improved" design fails to meet the
requirements that the old design met, in a way that makes the new design unusable, that's
a bug.
joe
On Sat, 2 May 2009 21:12:04 -0500, "Scot T Brennecke" <ScotB@MVPs.spamhater.org> wrote:
Well, although I generally agree with your assessment of making porr decisions in order to
provide
the "cool" "ribbon" "fluent UI" stuff, I disagree with the word "bug" here. A "bug" would
either
be
not implementing the code as designed, or breaking existing code without intending to do so (and
warning about it). Because these classes are all new, one can simply choose to not use them if
they
don't behave as you like. You can submit a Design Change Request if you'd like to use them, but
require changes before you can do so. But a bug report should be reserved for code not working
as
designed and/or breaking good code elsewhere without warning.
"Joseph M. Newcomer" <newcomer@flounder.com> wrote in message
news:ol6ev4la2tahfqjkegqg86gui2m94a2bkg@4ax.com...
The problem with "as intended" is that it also should mean "in ways consistent with
existing behavior". If the existing classes provided overrides, then it is a design error
to have not provided equivalent overrides. Microsoft has recently become infatuated with
the notion of "cool" and has been well and truly ignoring either "usable" or "right". So
this should be treated as a bug report, and it is UNACCEPTABLE to respond "it is working
as designed"; what the bug report would mean is "the design is broken, fix it!" The
failure to provide the facilities required is simply a design oversight, and needs to be
fixed.
Just a typical example: the Group Box in the latest common controls has a misfeature: if
it is disabled, it doesn't gray out. There is no reason to have done this, other than a
complete misunderstanding of what "disable" means. Now I have to go to a lot of work to
make a group box look disabled if I disable it, and why? Because someone ignored the
correct behavior to incorporate something into a "cool" set of features!
Don't even get me started on the "cool" Office ribbon bar. In an attempt to make it easy
for novices, they have made it impossible for experienced professionals. Because someone
ignored what was already possible in order to produce something "cool".
joe
On Tue, 28 Apr 2009 03:03:25 -0500, "Scot T Brennecke" <ScotB@MVPs.spamhater.org> wrote:
My experience has been that it provides a LOT of really cool UI stuff . . . if you use it the
way
the BCGSoft authors intended it, and a lot of people are quite happy to do so. But if you go
searching for overrides, it seems to (unfairly) strongly inhibit attempts to extend or modify
the
behaviors.
"Joseph M. Newcomer" <newcomer@flounder.com> wrote in message
news:ustbv45vac2s6fie060qicvqlp57hd7can@4ax.com...
All I can say is that more and more the "Feature Pack" is soundling like the "Misfeature
pack"...
joe
On Mon, 27 Apr 2009 03:49:01 -0700, Electronic75 <Electronic75@discussions.microsoft.com>
wrote:
Hello,
In an visual studio style MDI MFC application I want one of document
templates do not show close button.
I found this solution for old style MDI windows
//in a derived child frame Create()
CMenu *pSysMenu = GetSystemMenu(FALSE);
ASSERT(pSysMenu != NULL);
VERIFY(pSysMenu->RemoveMenu(SC_CLOSE, MF_BYCOMMAND));
as indicated in http://support.microsoft.com/kb/201553
but for new feature pack visual studio style tabbed document windows it
dose not work. Anybody has any solution?
thanks.
Joseph M. Newcomer [MVP]
email: newcomer@flounder.com
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
Joseph M. Newcomer [MVP]
email: newcomer@flounder.com
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
Joseph M. Newcomer [MVP]
email: newcomer@flounder.com
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm