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."
| Вернуться в корень Архива |