> Is this a recommended way to go?

> I've also seen that there's System.Drawing.*

> Is there a better one?

wrote:

> [...]
> In Java i'm used to override a components paintComponent (Graphics g)
> but that doesn't imply it's the way to solve it in C#.
> That's what i'm curious about.

>> Is this a recommended way to go?
> Looks about right; maybe call the base method first...
>
>> I've also seen that there's System.Drawing.*
> "Graphics " is part of System.Drawing, so this is a mute question
>
>> Is there a better one?
> If you want something funky, you might also look at WPF, then whole
> new GUI framework in .NET 3.0

> On Wed, 13 Feb 2008 21:47:47 -0800, K Viltersten <tmp1@viltersten.com>
> wrote:
>
>> [...]
>> In Java i'm used to override a components paintComponent (Graphics g)
>> but that doesn't imply it's the way to solve it in C#.
>> That's what i'm curious about.
>
> For the most part, your Java techniques will apply in .NET. They aren't
> exactly the same, but the general idea of always drawing in a specific
> method designed for the purpose and that method being called by the system
> to have you draw when needed applies in both cases. Since that's a
> central part of understanding how drawing works in both environments,
> you're way ahead of the game.
>
> You had a number of questions, so I don't think Marc's reply could have a
> simple "yes" or "no". If you're only asking specifically about the last
> question ("is there a better one?"), then that's difficult to answer
> without knowing what you're trying to do. WPF is supposed to provide in
> some respects a simpler, more broadly featured drawing API, but the
> pre-WPF drawing paradigm works just fine.
>
> Overriding OnPaint() is not only acceptable, it's a good way to do drawing
> assuming you don't have a specific desire to use WPF. Other than
> providing a handler for the Paint event, it's the only "right way" to do
> it (and in Control-inheriting classes, IMHO overriding the OnPaint()
> method is generally better).