Custom Control Issue: endless WM_PAINT

[Guest]

Hello All,

I am currently working on an issue that has a custom control that mimics a
combobox that when it has focus it continues to generate endless WM_PAINT
Messages. The control in itself is primarily a windows panel with three
controls added ( textbox, combo box, and picturebox). In looking at the
code for the custom control I see no issue with it.

Any pointers on how to determine which likely control in this custom control
is sending out the WM_PAINT messages?

Thank you in advance
Eric

 

[Peter Duniho]

[...]
Any pointers on how to determine which likely control in this custom
control is sending out the WM_PAINT messages?

If you literally get endless WM_PAINT messages and you never get a stack
overflow error, then it is actually more likely that a control is
invalidating when it redraws (a big no-no). So you should be looking for
a call to Invalidate(), rather than something like Refresh() or explicitly
sending WM_PAINT messages.

Note that changing values within a control also can cause the control to
be invalidated. Basically, the only thing that should happen in the Paint
event is to actually draw things. Nothing that affects the visual
appearance of a control should be called.

As for how to track down a specific problem control, I guess it depends on
what sort of access you have to the implementation of the control. But as
a first step, it seems like you could just use the process of
elimination. Remove one control at a time and when the problem goes away,
the last control you removed was the trouble-maker.

Pete

 

[Guest]

Thank you Peter,

Those pointers should assist me in determining which control is the problem.

Eric

[...]
Any pointers on how to determine which likely control in this custom
control is sending out the WM_PAINT messages?

If you literally get endless WM_PAINT messages and you never get a stack
overflow error, then it is actually more likely that a control is
invalidating when it redraws (a big no-no). So you should be looking for
a call to Invalidate(), rather than something like Refresh() or explicitly
sending WM_PAINT messages.

Note that changing values within a control also can cause the control to
be invalidated. Basically, the only thing that should happen in the Paint
event is to actually draw things. Nothing that affects the visual
appearance of a control should be called.

As for how to track down a specific problem control, I guess it depends on
what sort of access you have to the implementation of the control. But as
a first step, it seems like you could just use the process of
elimination. Remove one control at a time and when the problem goes away,
the last control you removed was the trouble-maker.

Pete