AutoRedraw property gone

[Chris Mack]

I'm trying to do some simple graphic manipulation in vb.net - stuff that would
be really simple in vb6, but I can't seem to find an equivalent to vb6's
autoRedraw property, so any lines, shapes, etc. I draw in .net dissappear
whenever the form is repainted.

I know the code can be placed in the form_paint event so that it does get
redrawn, but that doesn't work for dynamically added/removed graphics.

I've got a couple of books on vb.net, but neither really get into graphics,
and certainly don't mention anything about a replacement to the AutoRedraw
property.

Does anybody know what to use now?

Chris

[Jonathan Allen]

> I know the code can be placed in the form_paint event so that it does get
> redrawn, but that doesn't work for dynamically added/removed graphics.

You have to include the logic for the dynamic parts in the paint event.

--
Jonathan Allen



"Chris Mack" <cemack2000@yahoo.com> wrote in message
news:3bc96b09$1@news.devx.com...
>
> I'm trying to do some simple graphic manipulation in vb.net - stuff that
would
> be really simple in vb6, but I can't seem to find an equivalent to vb6's
> autoRedraw property, so any lines, shapes, etc. I draw in .net dissappear
> whenever the form is repainted.
>
> I know the code can be placed in the form_paint event so that it does get
> redrawn, but that doesn't work for dynamically added/removed graphics.
>
> I've got a couple of books on vb.net, but neither really get into
graphics,
> and certainly don't mention anything about a replacement to the AutoRedraw
> property.
>
> Does anybody know what to use now?
>
> Chris

[Larry Serflaten]

"Chris Mack" <cemack2000@yahoo.com> wrote
>
> I'm trying to do some simple graphic manipulation in vb.net - stuff that would
> be really simple in vb6, but I can't seem to find an equivalent to vb6's
> autoRedraw property, so any lines, shapes, etc. I draw in .net dissappear
> whenever the form is repainted.

I am just getting back into .Net after a long break, I am not certain this covers
what you want, because I have not used it. A little research on your part might
get the effect you are looking for. But, to begin, I suggest something like:

Public Sub New() 'Your Form's constructor

'Normal construction routines
MyBase.New()
Form1 = Me
InitializeComponent()

Me.SetStyle(ControlStyles.DoubleBuffer, True)
...

Check out the ControlStyles to see if something else may be more appropreate...
(Its a flag, so you may combine more than one style using OR)

Good Luck
LFS

[Matt Griffith]

On Sun, 14 Oct 2001 19:51:40 -0500, Larry Serflaten
<serflaten@usinternet.com> says...
> Me.SetStyle(ControlStyles.DoubleBuffer, True)

Nope, DoubleBuffer won't do what Chris needs. AFAIK you have to do it
yourself in Paint, as Jonathan said.

> Check out the ControlStyles to see if something else may be more appropreate...
> (Its a flag, so you may combine more than one style using OR)

Yes, ControlStyles can be OR'd.

Chris:

The Windows Forms team has a lot of great info on their GotDotNet web
site. Check it out:

http://www.gotdotnet.com/team/windowsforms/


Matt Griffith

[Chris]

Cheers guys,

Actually, I've been all over the gotdotnet site and msdn and can't really
find what I'm looking for.

I don't see how I can use the paint event, because the user dictates what
graphics are displayed through their actions, therefore, the only way I can
see to use the paint event is to create an object for each shape drawn,
store the x,y coordinates and drawing details etc. in each object, and then
in the paint event, cycle through all shape objects and paint them. This
seems like a bit of a round about way to do it.

Alternatively, I have been experimenting with using a PictureBox control -
those graphics can be repainted using a simple routine, but there are issues
with doing it that way too. It seems like there's no easy way to do
something that was very simple in VB6. It's a bit dissapointing really.

Thanks for the advice.

Chris
"Matt Griffith" <griffordson@hotmail.com> wrote in message
news:MPG.1635793990d41e71989683@news.devx.com...
> On Sun, 14 Oct 2001 19:51:40 -0500, Larry Serflaten
> <serflaten@usinternet.com> says...
> > Me.SetStyle(ControlStyles.DoubleBuffer, True)
>
> Nope, DoubleBuffer won't do what Chris needs. AFAIK you have to do it
> yourself in Paint, as Jonathan said.
>
> > Check out the ControlStyles to see if something else may be more
appropreate...
> > (Its a flag, so you may combine more than one style using OR)
>
> Yes, ControlStyles can be OR'd.
>
> Chris:
>
> The Windows Forms team has a lot of great info on their GotDotNet web
> site. Check it out:
>
> http://www.gotdotnet.com/team/windowsforms/
>
>
> Matt Griffith

[David Bayley]

Chris,

> I know the code can be placed in the form_paint event so that it does get
> redrawn, but that doesn't work for dynamically added/removed graphics.

Create a System.Drawing.Bitmap object, the same size as your form's
ClientSize. You can then get a System.Drawing.Graphics object from this
Bitmap using its CreateGraphics method (make sure you Dispose the Graphics
and Bitmap objects after you've finished with them, either at the end of the
method for local vars, or in the form's Dispose method for module vars).

This will be your in-memory painting canvas which you can dynamically draw
on. When you're ready to update the form, call Form.Invalidate() which will
trigger the Paint event. In the Paint event, get the form's Graphics object
from PaintEventArgs, and just call it's DrawImageUnscaled method to copy
your Bitmap onto the form.

If your form is resizable, you will need to recreate your Bitmap object in
the Resize event.

This is effectively what AutoRedraw does for you behind the scenes. It's a
little bit more work to set up, but after it's done the painting routines
are just as easy to write (and of course you benefit from all the great
System.Drawing classes).

--
David.

[Bill McCarthy]

Hi Chris,

In VB6 when AutoRedraw is set to True, VB stores a memory bitmap. Probably
an easy equivalent in .NET is to draw to an image and then just paint that.

"Chris" <chris.mack@triaster.co.uk.getridofthis> wrote in message
news:3bcbef0c@news.devx.com...
> Cheers guys,
>
> Actually, I've been all over the gotdotnet site and msdn and can't really
> find what I'm looking for.
>
> I don't see how I can use the paint event, because the user dictates what
> graphics are displayed through their actions, therefore, the only way I
can
> see to use the paint event is to create an object for each shape drawn,
> store the x,y coordinates and drawing details etc. in each object, and
then
> in the paint event, cycle through all shape objects and paint them. This
> seems like a bit of a round about way to do it.
>
> Alternatively, I have been experimenting with using a PictureBox control -
> those graphics can be repainted using a simple routine, but there are
issues
> with doing it that way too. It seems like there's no easy way to do
> something that was very simple in VB6. It's a bit dissapointing really.
>
> Thanks for the advice.
>
> Chris
> "Matt Griffith" <griffordson@hotmail.com> wrote in message
> news:MPG.1635793990d41e71989683@news.devx.com...
> > On Sun, 14 Oct 2001 19:51:40 -0500, Larry Serflaten
> > <serflaten@usinternet.com> says...
> > > Me.SetStyle(ControlStyles.DoubleBuffer, True)
> >
> > Nope, DoubleBuffer won't do what Chris needs. AFAIK you have to do it
> > yourself in Paint, as Jonathan said.
> >
> > > Check out the ControlStyles to see if something else may be more
> appropreate...
> > > (Its a flag, so you may combine more than one style using OR)
> >
> > Yes, ControlStyles can be OR'd.
> >
> > Chris:
> >
> > The Windows Forms team has a lot of great info on their GotDotNet web
> > site. Check it out:
> >
> > http://www.gotdotnet.com/team/windowsforms/
> >
> >
> > Matt Griffith
>
>

[Larry Serflaten]

"David Bayley" <dbayley@spamless.aebacus.com> wrote
>
> This is effectively what AutoRedraw does for you behind the scenes. It's a
> little bit more work to set up, but after it's done the painting routines
> are just as easy to write (and of course you benefit from all the great
> System.Drawing classes).

I don't want to sound sarcastic, the same could be said about much
of the language.

"You have to create your own command button, but once its done
you can add any property you want."

"You have to use the API to handle directory and file I/O, but a well
written class can be used in any of your later apps"

My point is that the purpose of a higher level language is to isolate the
programmer from the intricasies of the hardware. GDI++ is almost
little more than a (perhaps well designed) wrapper for even lower level
functions.

While it will be nice to leverage the power, the language has suffered a
big blow to 'ease of use' in this and other areas. But, perhaps since VB
is no longer a stand alone development system, MS has decided that
they do not need to cater to the 'casual' user (read domain experts).

No skin off my nose, but I hate to think of all the 'improvements' that
must be rewritten/re-introduced to make VB.Net easier to work with.
Either MS has to do it, or each developer has to invest more time and/or
money.

Oh well...
LFS

[Mark Jerde]

Larry,

> While it will be nice to leverage the power, the
> language has suffered a big blow to 'ease of use'
> in this and other areas. But, perhaps since VB
> is no longer a stand alone development system,
> MS has decided that they do not need to cater to
> the 'casual' user (read domain experts).

Interesting point.

Think MS would be willing to sell VB6 to a company willing to support it?

-- Mark

[Jonathan Allen]

> I don't see how I can use the paint event, because the user dictates what
> graphics are displayed through their actions, therefore, the only way I
can
> see to use the paint event is to create an object for each shape drawn,
> store the x,y coordinates and drawing details etc. in each object, and
then
> in the paint event, cycle through all shape objects and paint them. This
> seems like a bit of a round about way to do it.

That is they way it is traditionally done. One advantage of this method is
that it makes writing "Undo" code really easy. You just have to delete the
last item you put in the to-draw list.

--
Jonathan Allen



"Chris" <chris.mack@triaster.co.uk.getridofthis> wrote in message
news:3bcbef0c@news.devx.com...
> Cheers guys,
>
> Actually, I've been all over the gotdotnet site and msdn and can't really
> find what I'm looking for.
>
> I don't see how I can use the paint event, because the user dictates what
> graphics are displayed through their actions, therefore, the only way I
can
> see to use the paint event is to create an object for each shape drawn,
> store the x,y coordinates and drawing details etc. in each object, and
then
> in the paint event, cycle through all shape objects and paint them. This
> seems like a bit of a round about way to do it.
>
> Alternatively, I have been experimenting with using a PictureBox control -
> those graphics can be repainted using a simple routine, but there are
issues
> with doing it that way too. It seems like there's no easy way to do
> something that was very simple in VB6. It's a bit dissapointing really.
>
> Thanks for the advice.
>
> Chris
> "Matt Griffith" <griffordson@hotmail.com> wrote in message
> news:MPG.1635793990d41e71989683@news.devx.com...
> > On Sun, 14 Oct 2001 19:51:40 -0500, Larry Serflaten
> > <serflaten@usinternet.com> says...
> > > Me.SetStyle(ControlStyles.DoubleBuffer, True)
> >
> > Nope, DoubleBuffer won't do what Chris needs. AFAIK you have to do it
> > yourself in Paint, as Jonathan said.
> >
> > > Check out the ControlStyles to see if something else may be more
> appropreate...
> > > (Its a flag, so you may combine more than one style using OR)
> >
> > Yes, ControlStyles can be OR'd.
> >
> > Chris:
> >
> > The Windows Forms team has a lot of great info on their GotDotNet web
> > site. Check it out:
> >
> > http://www.gotdotnet.com/team/windowsforms/
> >
> >
> > Matt Griffith
>
>

[Jonathan Allen]

It may be painful now, but once we get the framework in place things will
get better.

For instance, once you create a form that supports AutoRedraw, all other
forms that need it can inherit from on it.

One classic problem with VB Option buttons is that you have to search
through them to find the one that is selected. Either that, or write a
handlers for each one to update a variable.

With VB.Net, I was able to easily create a custom Option Button and Frame.
The frame automatically attaches itself to the option button's click event.
The option button can then automatically update a property in the frame. All
this is done without a single line of code by the person using the controls.
I may never have to write an event handler for an option button again.

In short, it will be painful at first. But as the controls are built, things
will get easier.

--
Jonathan Allen



"Larry Serflaten" <serflaten@usinternet.com> wrote in message
news:3bcc64c6@news.devx.com...
> "David Bayley" <dbayley@spamless.aebacus.com> wrote
> >
> > This is effectively what AutoRedraw does for you behind the scenes.
It's a
> > little bit more work to set up, but after it's done the painting
routines
> > are just as easy to write (and of course you benefit from all the great
> > System.Drawing classes).
>
> I don't want to sound sarcastic, the same could be said about much
> of the language.
>
> "You have to create your own command button, but once its done
> you can add any property you want."
>
> "You have to use the API to handle directory and file I/O, but a well
> written class can be used in any of your later apps"
>
> My point is that the purpose of a higher level language is to isolate the
> programmer from the intricasies of the hardware. GDI++ is almost
> little more than a (perhaps well designed) wrapper for even lower level
> functions.
>
> While it will be nice to leverage the power, the language has suffered a
> big blow to 'ease of use' in this and other areas. But, perhaps since VB
> is no longer a stand alone development system, MS has decided that
> they do not need to cater to the 'casual' user (read domain experts).
>
> No skin off my nose, but I hate to think of all the 'improvements' that
> must be rewritten/re-introduced to make VB.Net easier to work with.
> Either MS has to do it, or each developer has to invest more time and/or
> money.
>
> Oh well...
> LFS
>
>
>
>
>

[Chris Mack]

Thanks guys, I've been playing around with this for a while now, and I'm a
little disadvantaged because I've never written a graphical app b4, but
things are starting to fit together in .Net (albeit slowly!!!)

I think Johnathan is right, there will be pain at first (and it IS
painful!!), but I can't help but think that it's worth it.


Chris

"Jonathan Allen" <greywolf@cts.com> wrote in message
news:3bccaeb9@news.devx.com...
> It may be painful now, but once we get the framework in place things will
> get better.
>
> For instance, once you create a form that supports AutoRedraw, all other
> forms that need it can inherit from on it.
>
> One classic problem with VB Option buttons is that you have to search
> through them to find the one that is selected. Either that, or write a
> handlers for each one to update a variable.
>
> With VB.Net, I was able to easily create a custom Option Button and Frame.
> The frame automatically attaches itself to the option button's click
event.
> The option button can then automatically update a property in the frame.
All
> this is done without a single line of code by the person using the
controls.
> I may never have to write an event handler for an option button again.
>
> In short, it will be painful at first. But as the controls are built,
things
> will get easier.
>
> --
> Jonathan Allen
>
>
>
> "Larry Serflaten" <serflaten@usinternet.com> wrote in message
> news:3bcc64c6@news.devx.com...
> > "David Bayley" <dbayley@spamless.aebacus.com> wrote
> > >
> > > This is effectively what AutoRedraw does for you behind the scenes.
> It's a
> > > little bit more work to set up, but after it's done the painting
> routines
> > > are just as easy to write (and of course you benefit from all the
great
> > > System.Drawing classes).
> >
> > I don't want to sound sarcastic, the same could be said about much
> > of the language.
> >
> > "You have to create your own command button, but once its done
> > you can add any property you want."
> >
> > "You have to use the API to handle directory and file I/O, but a well
> > written class can be used in any of your later apps"
> >
> > My point is that the purpose of a higher level language is to isolate
the
> > programmer from the intricasies of the hardware. GDI++ is almost
> > little more than a (perhaps well designed) wrapper for even lower level
> > functions.
> >
> > While it will be nice to leverage the power, the language has suffered a
> > big blow to 'ease of use' in this and other areas. But, perhaps since
VB
> > is no longer a stand alone development system, MS has decided that
> > they do not need to cater to the 'casual' user (read domain experts).
> >
> > No skin off my nose, but I hate to think of all the 'improvements' that
> > must be rewritten/re-introduced to make VB.Net easier to work with.
> > Either MS has to do it, or each developer has to invest more time and/or
> > money.
> >
> > Oh well...
> > LFS
> >
> >
> >
> >
> >
>
>

[Rob Teixeira]

Chris, see my response to Patrick Ireland.
It's a lot easier than people think (not to mention much more flexible, and
in some cases, a lot faster).

-Rob

"Chris Mack" <Cemack@btopenworld.com> wrote:
>Thanks guys, I've been playing around with this for a while now, and I'm
a
>little disadvantaged because I've never written a graphical app b4, but
>things are starting to fit together in .Net (albeit slowly!!!)
>
>I think Johnathan is right, there will be pain at first (and it IS
>painful!!), but I can't help but think that it's worth it.
>
>
>Chris
>