Text not writen in the console when (re)painting the window

[K Viltersten]

I've painted an ellipse on a form i'm
designing and it looks as expected.
Then, i noticed that it doesn't get
repainted as the size changes. To see
if the OnPain is called i added a
console print out.

The code looks as follows.

protected override void
OnPaint (PaintEventArgs e){
// painting stuff...
Console.WriteLine ("OnPaint invoked");}

Now, i do know that i paint because i
can see a damn ellipse on the screen
so why don't i see the text?! (Yes, i
started the EXE file from the console
window.)

 

[christery]

I've painted an ellipse on a form i'm
designing and it looks as expected.
Then, i noticed that it doesn't get
repainted as the size changes. To see
if the OnPain is called i added a
console print out.

The code looks as follows.

protected override void
OnPaint (PaintEventArgs e){
// painting stuff...
Console.WriteLine ("OnPaint invoked");}

Now, i do know that i paint because i
can see a damn ellipse on the screen
so why don't i see the text?! (Yes, i
started the EXE file from the console
window.)

some autoredraw property coes to mind from vb6... not shure, or as
yoda would have said "a form property there is, a new jedi will come..
"

$B%W%m%0%i%`$9$k$3$H$O:$Fq$G$"$k(B

//CY

 

[Bob Powell [MVP]]

Are you using visual studio? STDOUT will show up in the program output
window in this case.

Launching a windows forms program from a console doesn't map SDTOUT back to
the command window that u used.

--
--
Bob Powell [MVP]
Visual C#, System.Drawing

Ramuseco Limited .NET consulting
http://www.ramuseco.com

Find great Windows Forms articles in Windows Forms Tips and Tricks
http://www.bobpowell.net/tipstricks.htm

Answer those GDI+ questions with the GDI+ FAQ
http://www.bobpowell.net/faqmain.htm

All new articles provide code in C# and VB.NET.
Subscribe to the RSS feeds provided and never miss a new article.

 

[K Viltersten]

Are you using visual studio? STDOUT will

show up in the program output window in
this case.

Yes, VS2008 Express, but as far i can see
there's no text appearing in the output
window at run-time. (One can see the
results of compilation, of course.)

Launching a windows forms program from a
console doesn't map SDTOUT back to the
command window that u used.

Can i map it in an easy way? Alternatively
make the text appear in the output window?
Right now, i'm forced to go
this.richTextBox1.Text = "\npaint!" +
this.richTextBox1.Text;
instead of
Console.WriteLine ("paint!");
as it should be.

By the way, what's the difference between
these two?
Console.WriteLine ("paint!");
Console.Out.WriteLine ("paint!");

 

[Peter Duniho]

Yes, VS2008 Express, but as far i can see there's no text appearing in
the output
window at run-time. (One can see the results of compilation, of course.)

For this purpose, you may find the Debug class preferable. I wasn't aware
that stdout is supported for a non-console application, and/or that it
should show up in the Output window of VS at run-time. However, I can
tell you that for debugging purposes, the Debug.WriteLine() method is very
useful and IMHO more appropriate.

So that's one thing you might try instead.

By the way, what's the difference between
these two?
Console.WriteLine ("paint!");
Console.Out.WriteLine ("paint!");

None, as far as I know. The docs specifically say that
Console.WriteLine() writes to the "standard output stream", and that the
Console.Out property returns the "standard output stream".

By the way, with respect to your original question: you should note that
while you _will_ get a call to the OnPaint() method (or to a Paint event
handler) when the window is resized, only the newly exposed area will be
drawn. You should be seeing _something_ as you change the window size,
but for correct results you will need to handle the resize event (there
are actually a number of ways, including overriding OnResize()
OnSizeChanged(), or OnResizeEnd(), or handling one of the associated
events) and then invalidate the entire window (just call Invalidate())
when the size changes.

Pete

 

[K Viltersten]

...I can tell you that for debugging purposes, the

Debug.WriteLine() method is very useful

I'll try that as well. Thanks.

By the way, with respect to your original question: you
should note that while you _will_ get a call to the
OnPaint() method when the window is resized, only the
newly exposed area will be drawn. You should be seeing
_something_ as you change the window size...

I figured that one out after a while of WTF-experience. It
makes sense now but at first i was feeling retarded, hehe.

for correct results you will need to handle the resize event...
including overriding OnResize(), OnSizeChanged(), or
OnResizeEnd()... and then invalidate the entire window
(just call Invalidate()) when the size changes.

What i did was to use Refresh() after forwarding a call to the
base in OnResize() method as follows. Do you claim that
Invalidate() is more prefered? Why? (Not arguing, just curious.)

protected override void OnResize (EventArgs e) {
base.OnResizeEnd (e);
this.Refresh ();}

What do you think?

 

[Peter Duniho]

[...]
What i did was to use Refresh() after forwarding a call to the
base in OnResize() method as follows. Do you claim that
Invalidate() is more prefered? Why? (Not arguing, just curious.)

Yes. Invalidate() is vastly more appropriate than Refresh(), because it
allows Windows to efficiently manage window updates. Calling Refresh()
forces your UI to be updated right away, whether or not it's a good time
to do it. In the simplest cases, this may not be an immediate problem.
But it shortcuts the ability of Windows to consolidate updates and can
lead to less efficient code. It is much better to get into the habit of
using the standard methodology, so that you don't wind up doing the wrong
thing when it actually matters.

Note that Refresh() implicitly does an Invalidate() anyway. The only
difference is that it then immediately processes the pending window
updates, rather than allowing them to be handled through normal message
processing. So it's not like you're avoiding the Invalidate() by calling
Refresh() anyway.

Pete

 

[K Viltersten]

What i did was to use Refresh() after forwarding a call to the

Yes. Invalidate() is vastly more appropriate than Refresh(), because it
allows Windows to efficiently manage window updates.

Got it. I almost saw that coming, hehe. Thank you.