Paint message fire galore

[Guest]

Hi,

On a usercontrol I've put a set of radiobuttons within a groupbox. These
radiobuttons have visual style enables, i.e. they turn orange when hovering
over them and green when pushed.

Normally I put my updation of data shown in the controls on the usercontrol
in the Paint event handler of the usercontrol. When it comes to the
radiobuttons, a paint event for the usercontrol is fired whenever hovering
over the radiobuttons, making them impossible to change as they in the paint
event handler are set to reflect a given state.

Hoverver the problem is solved by putting the groupbox with the radiobuttons
on a panel on the usercontrol. The paint event for the control is now not
fired when hovering over it. Why?

Regards Jesper.

 

[Peter Duniho]

[...]
Normally I put my updation of data shown in the controls on the usercontrol
in the Paint event handler of the usercontrol. When it comes to the
radiobuttons, a paint event for the usercontrol is fired whenever hovering
over the radiobuttons, making them impossible to change as they in the paint
event handler are set to reflect a given state.

Hoverver the problem is solved by putting the groupbox with the radiobuttons
on a panel on the usercontrol. The paint event for the control is now not
fired when hovering over it. Why?

I don't know specifically. I suspect it has something to do with the
Panel buffering the drawing of the contained controls, but I can't say
for sure.

That said, the more general issue here is the question of what you
should or should not do in a Paint event handler. The answer to that
question is:

Should do: draw stuff
Should NOT do: anything else

The fact that you're doing something other than drawing in your paint
handler is the root cause of the issue you're seeing. Even if you can
avoid the immediate manifestation of the problem by moving the controls
to a Panel inside the UserControl, that doesn't mean you've addressed
the basic problem. It just means you've covered it up somehow. Who
knows when it will come back or how?

The correct solution is to change the flow of data, so that you only
Paint in response to changes in the data, and any updates to that data
is done in direct response to changes in the UI that are supposed to
update the data, rather than waiting until you have to redraw the UI to
propagate those changes.

Pete

 

[Guest]

Thanks Peter,

I have been using the paint event handler since MFC (I guess) to reflect my
data like this:

...._Paint(..)
{
textBox1.Text = someString;

//and

if ( true == foo )
{
radioButton1.Checked = true;
}
else
{
radioButton2.Checked = true;
}
}

Is this not good style?,
What's the alternative?

I appreciate the thread, it's quite important to me.
Regards Jesper.

[...]
Normally I put my updation of data shown in the controls on the usercontrol
in the Paint event handler of the usercontrol. When it comes to the
radiobuttons, a paint event for the usercontrol is fired whenever hovering
over the radiobuttons, making them impossible to change as they in the paint
event handler are set to reflect a given state.

Hoverver the problem is solved by putting the groupbox with the radiobuttons
on a panel on the usercontrol. The paint event for the control is now not
fired when hovering over it. Why?

I don't know specifically. I suspect it has something to do with the
Panel buffering the drawing of the contained controls, but I can't say
for sure.

That said, the more general issue here is the question of what you
should or should not do in a Paint event handler. The answer to that
question is:

Should do: draw stuff
Should NOT do: anything else

The fact that you're doing something other than drawing in your paint
handler is the root cause of the issue you're seeing. Even if you can
avoid the immediate manifestation of the problem by moving the controls
to a Panel inside the UserControl, that doesn't mean you've addressed
the basic problem. It just means you've covered it up somehow. Who
knows when it will come back or how?

The correct solution is to change the flow of data, so that you only
Paint in response to changes in the data, and any updates to that data
is done in direct response to changes in the UI that are supposed to
update the data, rather than waiting until you have to redraw the UI to
propagate those changes.

Pete

 

[Peter Duniho]

Thanks Peter,

I have been using the paint event handler since MFC (I guess) to
reflect my data like this:

...._Paint(..)
{
textBox1.Text = someString;

if ( true == foo )
{
radioButton1.Checked = true;
}
else
{
radioButton2.Checked = true;
}
}

Is this not good style?,

No, it's not a good style. Sorry to say, it was never a good style,
whether you were using MFC, or writing straight to the native Win32
API.

What's the alternative?

That's very hard to say without knowing what "someString" is and what
"foo" is. However, as a general rule of thumb, your design should be
changed so that when "someString" changes, that's where you set the
text in the TextBox, and when "foo" changes, that's where you change
the state of the RadioButton control.

Pete

 

[Guest]

Ok, I can appreciate that. I guess that initial population of data into
controls should be moved to the Load event handler (?).

What do you put in the paint event handler then - GDI+ stuff?

regards Jesper.

 

[Peter Duniho]

Ok, I can appreciate that. I guess that initial population of data
into controls should be moved to the Load event handler (?).

What do you put in the paint event handler then - GDI+ stuff?

Yes. Only commands that are specifically involved with drawing (or
"painting", if you will ). Many forms and controls have no need
for a custom Paint handler. You should only create a Paint event
handler or override OnPaint in a Control-derived class if you have
some specific need to provide a custom visual representation of the
Control. Other tasks are much better handled elsewhere.

Pete