clear fillEllipse graphics

[Slickuser]

I have this function that will fill the ellipse every 10 seconds with
specific x,y,w,h.

Now I want do the the reverse, to clear the ellipse with given x,y
using Timer at every 30s.
Or I have put these (x,y,w,h) to an array?
Later go back the array and fill ellipse with the same color as
background?

Is there an easy way?

Thanks..

//Sample code that draw with timer

private void drawNote(int x, int y, int width, int height,
SolidBrush brush)
{
Graphics graphicGlobal = this.CreateGrap hics();
this.Show();

graphicGlobal.F illEllipse(brus h, x, y, width, height);

}

// Timer to draw
private void timer_note_Tick (object sender, EventArgs e)
{
SolidBrush colorBrush = new SolidBrush(Colo r.Cyan);
SolidBrush colorBrush2 = new SolidBrush(Colo r.Magenta);

drawNote(x_glob al, y_global, width_global, height_global,
colorBrush);

drawNote(x_glob al + 15, y_global + 15, width_global,
height_global, colorBrush2);

x_global = x_global + 30;
y_global = y_global + 30;
}

[Peter Webb]

Peter:

I have been following this thread, as I have similar problems/issues (as you
may recall).

Since your last round of advice, I have played a lot, and even bought a C#
book, but its still not working. After many hours without luck, I would
really appreciate some more help

In my case, the OnPaint command would be extremely easy to implement as I am
drawing entirely to a graphics buffer (so I have a complete copy of the
image) and all I need to do is execute a MyBuffer.Render () to physically
redraw.

Here is my problem.

I have put this code into my app:

protected override void OnPaint(object sender, PaintEventArgs
pea)
{
MyBuffer.Render ();
}

This actually works, but only sort-of. This OnPaint is triggered by a redraw
of Form1. I start my app, it comes up with a blank PictureBox1. As soon as I
move the mouse off the PictureBox (eg to the button area) it triggers the
above and my image appears. But only (very annoyingly) when the user moves
the mouse to the button area. This is very inconvenient because I can't play
my animation on start up (and it looks tacky).

Clearly, I have wired the OnPaint to the Form, and not to PictureBox1.

My book says that I need to insert the OnPaint override in the control
setup. I can do this for Form1, because the system generates a block of code
to initialise Form1. I can find no equivalent for PictureBox1.

If I click on my PictureBox1 in the designer, it has a Paint method
(member?) listed, but this is Paint but not OnPaint. I can't see where my
On_Paint method has to be inserted in my code to trigger off PictureBox1
instead of Form1.

Somebody suggested that I create a custom control which inherits from
PictureBox but overrides OnPaint. I tried this, but got into a fair amount
of mess. I have abandoned this as it seemed a very complicated solution to a
pretty simple problem, and I got even further out of my depth.

So, is there a simple way of wiring my OnPaint method (which works fine) to
be triggered off a repaint of PictureBox1 instead of Form1? If so, how do I
do it?

Thanks,

Peter Webb

[Peter Duniho]

On Sat, 01 Dec 2007 17:59:11 -0800, Peter Webb
<we********@DIE SPAMDIEoptusnet .com.auwrote:

[...]
So, is there a simple way of wiring my OnPaint method (which works fine)
to be triggered off a repaint of PictureBox1 instead of Form1? If so,
how do I do it?

It seems to me that you actually have two different issues. One is, where
to do the drawing? That is, where does your drawing code go? The other
is, how do you cause the drawing to occur?

With respect to the first question...

The PictureBox class is not for people who want to do their own drawing.
It's a convenient control to which you can attach an existing Image, and
let the control itself deal with a variety of display issues. Such as,
when to draw, if and how to scale the image, that sort of thing.

You _could_ certainly derive a new class from PictureBox and override the
OnPaint() method, but that would be sort of pointless. You can easily do
the same thing deriving from the Control class, without having all the
extra PictureBox functionality dragged along.

You could also handle the PictureBox's Paint event, but again it would be
pointless, for the same reasons.

The reason for deriving from PictureBox would be if you want to use and
extend or override functionality that is specific to the PictureBox
class. So far I haven't seen anything that would suggest that's what
you're doing or what you want.

So where should you do the drawing? IMHO, it depends on what your UI is
like, which I don't know. If you intend to manage all of the drawing
inside the form, then drawing in the form class would be a reasonable
place. If, however, you want to be able to use the VS Designer to
implement and maintain the user interface, and you want to be able to
manipulate where you custom drawing happens as part of that maintenance,
then you will probably want to create a custom Control-derived class.
That way, you'll get a custom control added to your Designer toolbox that
you can drag and drop, placing it wherever you like.

Creating a custom control is very simple, practically the same as creating
a new form class. Just add a new item to the project (using the
Project/Add New Item... menu or the Solution Explorer), and select "Custom
Control" from the template list. This will create a new class derived
from Control. In that class, you can override OnPaint() where you want to
draw.

Of course, you will want to move any other code related to managing the
graphics into that control class, or somewhere related to it. That's a
broader design question, and frankly it's much harder to answer those
questions in a newsgroup like this. Providing good advice on design
generally requires a lot of background knowledge of the problem being
solved, and not only is that background knowledge difficult to express in
this context, so too is explaining how a good design would work.

Suffice to say, a good design makes it easy to put all your pieces
together. Conversely, if you're having trouble putting the pieces
together, you should rethink the design.

Now, finally...there 's the question of how to cause the drawing to occur.
The basic mechanism is invalidation of the control. In this context
"invalidati on" means something very specific: to communicate to Windows
that an area of the control no longer has valid graphics and needs to be
redrawn. You use the Control.Invalid ate() method to do this.

I've already explained that in this thread, and I believe that the various
links that have been posted, by myself and others, also explain it
reasonably well. The basic idea is this though: you don't draw in direct
reaction to changes in the data; you design your drawing code so that it
can always draw whatever the current state of the data is, and you
invalidate the control in reaction to changes to data.

Since you're using the BufferedGraphic s class, it seems to me that this
should be especially simple. When you change the BufferedGraphic s by
drawing to it, you need to call Invalidate() on whatever control it is
that you are drawing to (the Form class inherits Control as well). If you
know specifically what area of the BufferedGraphic s has changed, you can
use that information to restrict the invalidated area, passing a rectangle
to the Invalidate() method so that only the part that changed winds up
getting redrawn.

Pete