When the messagebox disappears, it leaves a white square

[pcnerd]

I've created a demo program that draws random lines on the form. At the end,
a messagebox pops up with the words"I'm done!". When I click on "OK", the
messagebox disappears, but a white square is left in its place. I can still
see the randomly drawn lines on the form, but some are covered up by the
white square. How do I prevent the white square from showing after the
messagebox closes? Thank you. David

[iwdu15]

if you are using the "Graphics" object to draw lines, this will happen. just
as your lines will go away if you minimize your app. you can either
dynamically create an array to keep track of all the points you draw, or the
way i prefer which is to use a GrpahicsPath object. take a look at the
GraphicsPath and "Start Figure" items. they should be what your looking for,
ive used them and they worked prefectly
--
-iwdu15

[pcnerd]

I am using the graphics object. Is there an alternative to using the
graphics object for drawing lines? I want to keep it simple because I'm a
newbie to VB.NET. Do I find info on the GraphicsPath object & the Start
Figure in the Help? I've noticed that the same problem happens when I use a
menu. When the menu disappears, there is a blank area. I don't have this
problem with the "same" demo program in VB6. When I click on the messagebox,
it disappears & I can still see the lines.

"iwdu15" wrote:

if you are using the "Graphics" object to draw lines, this will happen. just
as your lines will go away if you minimize your app. you can either
dynamically create an array to keep track of all the points you draw, or the
way i prefer which is to use a GrpahicsPath object. take a look at the
GraphicsPath and "Start Figure" items. they should be what your looking for,
ive used them and they worked prefectly
--
-iwdu15

[Michel Bru]

pcnerd a écrit :

but a white square is left in its place.

It has maybe nothing to do with the program but with ... your graphic
memory. Not enough memory. Check that you free all the objects you use.
Could be!

Michel.

[iwdu15]

no, its not the graphics memory, if you do not do your drawing in the forms
"OnPaint" method, then when something covers the form, the graphics are lost.
try this, create a sample app and put a button on the form, in the button
click event, draw a couple lines. minimize the form, the bring it back up.
the lines are gone, now if you do the same thing but put the drawing events
in the forms "Paint" event, the lines will stay so in the button click even,
put Me.Invalidate() and in the Paint event, put the drawing code. voila!

so to answer your question, you have to do one of the following: all drawing
in the Paint event, keep track of the points you draw and redraw the lines
when necessary, or use a GraphicsPath object, which you can read about in
help under System.Drawing2 D
--
-iwdu15

[Dennis]

A faster option is to do your drawing on a bitmap then in the form's
"onpaint" event, copy the bitmap to the form's graphics object using the API
"bitblt".
--
Dennis in Houston
"iwdu15" wrote:

no, its not the graphics memory, if you do not do your drawing in the forms
"OnPaint" method, then when something covers the form, the graphics are lost.
try this, create a sample app and put a button on the form, in the button
click event, draw a couple lines. minimize the form, the bring it back up.
the lines are gone, now if you do the same thing but put the drawing events
in the forms "Paint" event, the lines will stay so in the button click even,
put Me.Invalidate() and in the Paint event, put the drawing code. voila!

so to answer your question, you have to do one of the following: all drawing
in the Paint event, keep track of the points you draw and redraw the lines
when necessary, or use a GraphicsPath object, which you can read about in
help under System.Drawing2 D
--
-iwdu15

[Theo Verweij]

Using the OnPaint event can give serious performance problems!
As soon as anything has to be (re)painted on your form, you get this
event and your drawcode will execute.

A better way is to use the background image of the form; create a
bitmap, draw on this bitmap, and set this bitmap as background image.
In this way, your drawing will be automaticly updated by the window
repaints.
Dennis wrote:

A faster option is to do your drawing on a bitmap then in the form's
"onpaint" event, copy the bitmap to the form's graphics object using the API
"bitblt".

[pcnerd]

Now you are totally confusing me! I've gotten different suggestions. I'm
going to put the drawing code in the paint event & put me.invalidate in the
button click event. Something really weird is happening to the random lines
demo. After the 3rd buton click, the lines are drawn & then the form clears
itself!! The next time that I click the button, the lines are drawn again.
Really weird!! Why would it do that?

"Theo Verweij" wrote:

Using the OnPaint event can give serious performance problems!
As soon as anything has to be (re)painted on your form, you get this
event and your drawcode will execute.

A better way is to use the background image of the form; create a
bitmap, draw on this bitmap, and set this bitmap as background image.
In this way, your drawing will be automaticly updated by the window
repaints.
Dennis wrote:

A faster option is to do your drawing on a bitmap then in the form's
"onpaint" event, copy the bitmap to the form's graphics object using the API
"bitblt".

[Theo Verweij]

What happens when you put me.refresh after me.invalidate?

pcnerd wrote:

Now you are totally confusing me! I've gotten different suggestions. I'm
going to put the drawing code in the paint event & put me.invalidate in the
button click event. Something really weird is happening to the random lines
demo. After the 3rd buton click, the lines are drawn & then the form clears
itself!! The next time that I click the button, the lines are drawn again.
Really weird!! Why would it do that?

"Theo Verweij" wrote:

>Using the OnPaint event can give serious performance problems!
As soon as anything has to be (re)painted on your form, you get this
event and your drawcode will execute.

A better way is to use the background image of the form; create a
bitmap, draw on this bitmap, and set this bitmap as background image.
In this way, your drawing will be automaticly updated by the window
repaints.
Dennis wrote:

>>A faster option is to do your drawing on a bitmap then in the form's
"onpaint" event, copy the bitmap to the form's graphics object using the API
"bitblt".

[Dennis]

Is setting the background of the form to the bitmap quicker than using the
API "Bitblt" to copy the invalidated section to the form's graphic object in
the "onpaint" event?
--
Dennis in Houston
"Theo Verweij" wrote:

Using the OnPaint event can give serious performance problems!
As soon as anything has to be (re)painted on your form, you get this
event and your drawcode will execute.

A better way is to use the background image of the form; create a
bitmap, draw on this bitmap, and set this bitmap as background image.
In this way, your drawing will be automaticly updated by the window
repaints.
Dennis wrote:

A faster option is to do your drawing on a bitmap then in the form's
"onpaint" event, copy the bitmap to the form's graphics object using the API
"bitblt".