WM_CTLCOLOR WinNT vs. Win95 Differences
Mark Ramberg -- MarkRa@asymetrix.com
Monday, February 12, 1996
I've noticed some odd behavior and inconsistency between Windows NT(3.51,
service pack 3) and Windows 95. I've got a dialog which has a couple of
owner drawn controls in it. These controls are laid out as static frames
in the resource editor and painted in the handler for WM_CTLCOLOR.
This code has worked perfectly since MFC 1.5 and has gone through the
upgrade to MFC 2.x and now to MFC 4.0. What I'm noticing is that these
controls get drawn properly when the app is run under Windows 95, but if
it is run under Windows NT they don't get drawn. After putting a TRACE
into the message handler it was clear that under Windows NT the app is
not receiving the WM_CTLCOLOR message at all.
Now, after looking at the MFC source(WINCORE.CPP) I notice that the
WM_CTLCOLOR is now an obsolete message and that it has been broken out
into various messages such as WM_CTLCOLORSTATIC, etc. The MFC source
handles these messages in the function OnNTCtlColor( ) which sets up an
MFC structure and passes the message off to the windproc directly( return
WindowProc(WM_CTLCOLOR, 0, (LPARAM)&ctl); ).
Anyway, I'm trying to figure out how to handle the drawing of these owner
drawn controls so that they work properly in both Windows NT and Windows
95. And I'm not intested in any lectures about how the controls should be
self drawn. This is legacy code that I don't feel like re-writing.
Thanks,
Mark Ramberg
markra@asymetrix.com
Brad Wilson -- bradw@netnet.net
Wednesday, February 14, 1996
> I've noticed some odd behavior and inconsistency between Windows NT(3.51,
> service pack 3) and Windows 95. I've got a dialog which has a couple of
> owner drawn controls in it. These controls are laid out as static frames
> in the resource editor and painted in the handler for WM_CTLCOLOR.
Since static frames don't have an "owner draw" style to them, I'm a little
curious why you're doing it this way. Certainly, WM_CTLCOLOR is a bad
place to presume that painting needs to happen. WM_PAINT (and it's
owner draw send-to-the-parent equivilent, WM_DRAWITEM) is the only place
where you should presume that painting is necessary.
Do one of the following two things:
(a) keep static frames, derive a class from CStatic, override OnPaint,
and subclass the frames for painting, or
(b) use owner draw buttons instead, override OnDrawItem() in the dialog
and paint the items
If what you're painting should not have the functionality of a button,
it's a good idea to set "Disabled" and unset "Tab Stop" on the button.
I have used both of these techniques, and I find (b) is easier, since
I don't need to derive a class to do it. Of course, from the OO purist
point of view, (a) is more correct, since the paint code for each of
your items is clearly separated (rather than a switch on an ID in the
OnDrawItem of the dialog).
Your opinions may vary. :-)
> Now, after looking at the MFC source(WINCORE.CPP) I notice that the
> WM_CTLCOLOR is now an obsolete message and that it has been broken out
> into various messages such as WM_CTLCOLORSTATIC, etc. The MFC source
> handles these messages in the function OnNTCtlColor( ) which sets up an
> MFC structure and passes the message off to the windproc directly( return
> WindowProc(WM_CTLCOLOR, 0, (LPARAM)&ctl); ).
This is true, and has been completely documented (in the porting guide
and the Win32 API) since the first betas of NT 3.1 that I saw. This, of
course, is one of the (moderately) bad things about MFC: it insulates
you from the details which may be important to you. On the other hand,
they did an outstanding job making 16-bit MFC apps work under 32-bit with
as minimal changes as necessary, and is very useful as a common source
base for 16- and 32-bit applications.
Again, your opinions may vary. :-)
> Anyway, I'm trying to figure out how to handle the drawing of these owner
> drawn controls so that they work properly in both Windows NT and Windows
> 95. And I'm not intested in any lectures about how the controls should be
> self drawn. This is legacy code that I don't feel like re-writing.
We were doing so well up until this point.
[ "Brad turns into a jerk" mode: on ]
Look, get off your lazy {expletive} and do the thing the right way. I'm
really sorry you don't want to get lectures about how to do it the right
way (you're obviously, by virtue of this sentence, aware that you are
current doing it the wrong way). I get sick and tired of professionals
acting like little kids when their hacks don't work, because they didn't
do things the right way from day one. Microsoft has GIVEN you -- not one,
but two! -- methods to do what you want to do. The fact that you have
chosen method three -- when there _was_ _no_ method three -- just shows
how immature this decision was.
Your code is broken. You seem to know your code is broken. You cannot
fix broken code without work. Sorry you don't want to work today, but
that's life. If you don't want "lectures" about how to do things the
right way, don't ask this group for help any more. I'm sure I speak
for quite a few people when I say that I do a lot of work during the
day. I'm taking my own time to sit here and answer questions for people,
in the hopes that when I need one answered, people can help me. We don't
need runny-nosed little children like you telling us that we shouldn't
tell you how to do it the right way. People like you spoil the whole
purpose of groups like this.
Both of the solutions I gave you should be easily implementable in an
afternoon (presuming that you're not doing the wrong thing in hundreds
of places in your application). The vast majority of the work for both
of these solutions is cut-and-paste.
By the way, you should never start sentences with the word "and" (that's
what commas are for, not periods).
[ "Brad turns into a jerk" mode: off ]
Who needs a beer?
Brad
--
class CBradWilson : public CWorldWatchProgrammingTeam {
public:
void GetInetAddr ( CString& s ) { s = "bradw@exptech.com"; }
void GetE164Addr ( CString& s ) { s = "+1 (810) 620-9803"; }
void GetURL ( CString& s ) { s = "http://www.exptech.com"; }
void GetDisclaimer( CString& s ) { s = "All I say is fact :-p"; }
};
// QOTW: "Music nowadays is merely the art of executing difficulties and in
// the end that which is only difficult ceases to please."
| Вернуться в корень Архива
|