Re: Sometimes repainting has tiny warping effect
From: Jeff Partch [MVP] (jeffp_at_mvps.org)
Date: 05/11/04
- Next message: Jerry Coffin: "Re: Color of IDC_STATIC"
- Previous message: Trevor: "Re: Color of IDC_STATIC"
- In reply to: Joseph M. Newcomer: "Re: Sometimes repainting has tiny warping effect"
- Next in thread: Yasoo: "Re: Sometimes repainting has tiny warping effect"
- Messages sorted by: [ date ] [ thread ]
Date: Tue, 11 May 2004 09:22:00 -0500
"Joseph M. Newcomer" <newcomer@flounder.com> wrote in message
news:mn80a09td2lu9cjuolhp0r9uiim2j020ko@4ax.com...
> I didn't recommend it; I answered a question on how to deal with a problem
that seemed to
> be the result of something odd.
Well, perhaps recommend was the wrong word. You said that it was what you
would do.
>
> And yes, I have focused on a number of different problems.
Never focused on them publicly that I can recall. Even when I asked what
sort of problems you meant all you could come up with was this edit control
business.
> Edit control frames were the
> most annoying, but I've had problems where images which were drawn
directly on the dialog
> were not getting refreshed properly, where controls were being overwritten
by background,
> and so on. Since not one of the cases I have found ever actually made
sense, and would
> have been more sanely handled by having a separate child control on which
the drawing
> would be done, I simply removed the offending code, replacing it with what
turned out to
> be simpler, cleaner code. I have discovered that there are strange
problems which even
> doing everything "right" seems to not produce the desired result.
I've nothing against the second control technique, but I have never had all
these problems you keep hinting at.
>
> Therefore, I do not recommend this practice. I have lost count of all the
numerous
> problems I've seen, but every one of them was due to drawing directly on
the dialog.
Can you provide or suggest a repro of even one such problem? I'm really
interested in seeing it and trying to understand it.
>
> I think this is something that beginners try. I tried it when I was a
beginner. But the
> more experience I have, the more I find that this technique merely
generates problems, and
> that using subclassed CWnd or CStatic solves the problem. Usually in a
simpler fashion.
> For example, the incredibly complexity of code to draw a bitmap on the
dialog is replaced
> by a single CStatic::SetBitmap, a distinct improvement (and drawing
bitmaps is one of the
> most common things I see...in fact, I have people drawing bitmaps on the
dialog when the
> correct approach would be SetIcon---it is amazing how many of the bitmaps
are icon-sized!)
No doubt, but that seems like a side issue.
>
> The edit control border was one I fought for nearly a week before I
discovered the lurking
> code to erase the background explicitly written in the dialog's OnPaint
handler...and it
> was not aided by the fact that the clever programmer, to "minimize
compilation time" had
> moved the OnPaint handler to a separate file! "I was making a lot of
changes, and I didn't
> want to spend a lot of time compiling all the rest of the dialog code" he
said. Of course,
> he was using precompiled headers and incremental compilation and linking.
Go figure. So
> this particular problem sticks in my mind more than most.
That sounds like a specific problem with a specific implementation, and a
lot of window dressing.
>
> The skewed-drawing-of-moving-objects has been a serious problem, for
reasons I no longer
> recall. It was a plot line, which exhibited unfortunate discontinuities.
When I removed
> the code from the dialog's OnPaint handler and put it, essentially
unchanged, in the
> OnPaint handler of a CStatic, the problem disappeared. I have no idea why
it existed, but
> moving it out of the dialog OnPaint solved the problem. Another indicator
that There Is
> More Going On Than We Are Meant To Know.
I really believe that there isn't any more going on than I described.
Dialogs do not do any painting in response to WM_PAINT. They render their
background in response to WM_ERASEBKGND and do nothing out of the ordinary
or unexpected.
>
> So I make it a policy to avoid all OnPaint handlers in dialogs. I've done
some moderately
> sophisticated graphics, and I've never been hurt by this decision. But I
have lots of
> clients who were hurt by choosing to draw on the dialog. (Of course, I
made money fixing
> these problems, so I probably shouldn't complain too loudly).
Could it be that WM_PAINT is the wrong message to handle? I've been painting
on the dialog background in response to WM_ERASEBKGND for over 12 years and
never had anything like the troubles you describe. I'll admit that I do
vaguely recall a problem with a webbrowser control repainting, and that I
don't remember the details of it, but it wasn't reason enough to make me
forswear the practice. Surely, if it were as problematic as you describe I
expect I would have seen it by now.
- Next message: Jerry Coffin: "Re: Color of IDC_STATIC"
- Previous message: Trevor: "Re: Color of IDC_STATIC"
- In reply to: Joseph M. Newcomer: "Re: Sometimes repainting has tiny warping effect"
- Next in thread: Yasoo: "Re: Sometimes repainting has tiny warping effect"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|
