Panel Painting ghost

  • Thread starter Thread starter Peteroid
  • Start date Start date
P

Peteroid

When the application I'm working on is run it creates a panel with a Paint
event customized to draw primitives (circles, rectangles, etc.), places the
panel on a form, and then launches the form.

The weird part is, the panel, in the instant it becomes visible, seems to
have an image of what this panel had in it the LAST TIME THE APPLICATION WAS
RUN! Since this panel is created anew every time the application is run
('natch), this seems odd to me. I call this the 'ghost image'.

Context, some of which might help:

(*) VS C++.NET 2005 Express
(*) Panel DoubleBuffered = true ;
(*) Panel created in stack syntax in main()
(*) Form created in stack syntax in main()
(*) Custom Paint handler is += to Panel
(*) Custom Paint handler just draws primitives

I've also noticed that everytime the form is moved the panel's Paint event
fires twice. But, it looks like when the form/panel are first shown the
panel's Paint event only fires once. When the form is moved it doesn't
exhibit this behavior (the painted image remains solid and doesn't flicker).

It also (visually) seems to be a 3-part entry. It shows the 'ghost' image,
then it clears (black in my case), then shows my graphics (shows what paint
says). That is, it flickers. If it only showed the 'ghost image' and then my
graphics it would not flicker, as my graphics are static (don't animate at
all)..

It does this in both release and debug, both inside the GUI and stand-alone
exe's.

As all I do is create the panel, set-up panel graphics (paint handler), add
to form, and then show form (in that order), it can't be my code setting
things up 'late' after the form has been shown causing this behavior.

Is this possibly a known bug, or what? I can't imagine there is any code I
could write that could intentionally cause this behavior without it being
some problem in the system somehow.

Any comments? Thanks in advance for responses! : )

[==P==]
 
Peteroid... First, just use main to unit test or launch your app, not to
actually create an application. For a winforms c++/cli project main just
creates an object as in:

[STAThreadAttribute]
int main(array<System::String ^> ^args)
{
// Enabling Windows XP visual effects before any controls are created
Application::EnableVisualStyles();
Application::SetCompatibleTextRenderingDefault(false);

// Create the main window and run it
Application::Run(gcnew Form1());
return 0;
}

So create your application in a class and create an instance of the class in
main.

Second, I usually just override OnPaint as in:

protected override void OnPaint(PaintEventArgs e)
{
Graphics g= e.Graphics;
foreach (IDrawableShape ds in drawHistory)
{
ds.DrawYourself(g);
}
}

Apologies for the C# code.

Third, in general unless you need RAII behaviour, I would use gcnew for
reference types and let the garbage disposer manage releasing managed
resources. So outside of classes with an explicitly declared destructor use
gcnew. Use stack semantics for value types and classes with an explicitly
declared destructor which now in C++/cli maps to Dispose.

Personally, I see no problem with letting the wizard create the basic
winforms project and then adding your logic to project.

Hope that helps.

Peteroid said:
When the application I'm working on is run it creates a panel with a Paint
event customized to draw primitives (circles, rectangles, etc.), places the
panel on a form, and then launches the form.

The weird part is, the panel, in the instant it becomes visible, seems to
have an image of what this panel had in it the LAST TIME THE APPLICATION WAS
RUN! Since this panel is created anew every time the application is run
('natch), this seems odd to me. I call this the 'ghost image'.

Context, some of which might help:

(*) VS C++.NET 2005 Express
(*) Panel DoubleBuffered = true ;
(*) Panel created in stack syntax in main()
(*) Form created in stack syntax in main()
(*) Custom Paint handler is += to Panel
(*) Custom Paint handler just draws primitives

I've also noticed that everytime the form is moved the panel's Paint event
fires twice. But, it looks like when the form/panel are first shown the
panel's Paint event only fires once. When the form is moved it doesn't
exhibit this behavior (the painted image remains solid and doesn't flicker).

It also (visually) seems to be a 3-part entry. It shows the 'ghost' image,
then it clears (black in my case), then shows my graphics (shows what paint
says). That is, it flickers. If it only showed the 'ghost image' and then my
graphics it would not flicker, as my graphics are static (don't animate at
all)..

It does this in both release and debug, both inside the GUI and stand-alone
exe's.

As all I do is create the panel, set-up panel graphics (paint handler), add
to form, and then show form (in that order), it can't be my code setting
things up 'late' after the form has been shown causing this behavior.

Is this possibly a known bug, or what? I can't imagine there is any code I
could write that could intentionally cause this behavior without it being
some problem in the system somehow.

Any comments? Thanks in advance for responses! : )

[==P==]
Click to expand...
 
Hi JAL,

I think you're talking more about programming style than the problem I'm
talking about. But ,that being said...

I like to create console C++ projects because I use the console to put debug
helpers (I can use the console to display info in real time without having
to stop and inspect with the debugger). However, I do create my own Form
class (derived from System::Form) and launch it, so this is somewhat
equivalent to your suggestion of putting my application in a class and
creating an instance of it. It just happenes to also be a form! : ) I also
don't really like Winform projects since I like as much control of the
source as possible, and Winform adds its own stuff based on GUI interface
modifications.

As I'm using '/clr:pure', ALL of my code is garbage collected. The only
thing close to unmanaged code is I use '*' type pointers to doubles. I've
tried the 'clr/safe' setting. That generates over 6000 errors, so I'm not
going there... lol

I do, indeed, overrride the Paint event and put in my handler, one that
looks remarkable like the one you provided (basically, draw the graphic
primitives in a list). It is prefaced by an 'update' method to make sure
what it is shown reflects the current state of the application.

Now I have to assume anything that can be done in a winform project can be
done in a console project with the proper setup.

All of this does not explain how the state on a new Panel in a new
application run could possible start with the image of what was in 'this'
Panel the last time the application was executed. That just shouldn't happen
for ANY reason...

[==P==]





JAL said:
Peteroid... First, just use main to unit test or launch your app, not to
actually create an application. For a winforms c++/cli project main just
creates an object as in:

[STAThreadAttribute]
int main(array<System::String ^> ^args)
{
// Enabling Windows XP visual effects before any controls are created
Application::EnableVisualStyles();
Application::SetCompatibleTextRenderingDefault(false);

// Create the main window and run it
Application::Run(gcnew Form1());
return 0;
}

So create your application in a class and create an instance of the class
in
main.

Second, I usually just override OnPaint as in:

protected override void OnPaint(PaintEventArgs e)
{
Graphics g= e.Graphics;
foreach (IDrawableShape ds in drawHistory)
{
ds.DrawYourself(g);
}
}

Apologies for the C# code.

Third, in general unless you need RAII behaviour, I would use gcnew for
reference types and let the garbage disposer manage releasing managed
resources. So outside of classes with an explicitly declared destructor
use
gcnew. Use stack semantics for value types and classes with an explicitly
declared destructor which now in C++/cli maps to Dispose.

Personally, I see no problem with letting the wizard create the basic
winforms project and then adding your logic to project.

Hope that helps.

Peteroid said:
When the application I'm working on is run it creates a panel with a
Paint
event customized to draw primitives (circles, rectangles, etc.), places
the
panel on a form, and then launches the form.

The weird part is, the panel, in the instant it becomes visible, seems to
have an image of what this panel had in it the LAST TIME THE APPLICATION
WAS
RUN! Since this panel is created anew every time the application is run
('natch), this seems odd to me. I call this the 'ghost image'.

Context, some of which might help:

(*) VS C++.NET 2005 Express
(*) Panel DoubleBuffered = true ;
(*) Panel created in stack syntax in main()
(*) Form created in stack syntax in main()
(*) Custom Paint handler is += to Panel
(*) Custom Paint handler just draws primitives

I've also noticed that everytime the form is moved the panel's Paint
event
fires twice. But, it looks like when the form/panel are first shown the
panel's Paint event only fires once. When the form is moved it doesn't
exhibit this behavior (the painted image remains solid and doesn't
flicker).

It also (visually) seems to be a 3-part entry. It shows the 'ghost'
image,
then it clears (black in my case), then shows my graphics (shows what
paint
says). That is, it flickers. If it only showed the 'ghost image' and then
my
graphics it would not flicker, as my graphics are static (don't animate
at
all)..

It does this in both release and debug, both inside the GUI and
stand-alone
exe's.

As all I do is create the panel, set-up panel graphics (paint handler),
add
to form, and then show form (in that order), it can't be my code setting
things up 'late' after the form has been shown causing this behavior.

Is this possibly a known bug, or what? I can't imagine there is any code
I
could write that could intentionally cause this behavior without it being
some problem in the system somehow.

Any comments? Thanks in advance for responses! : )

[==P==]
Click to expand...
Click to expand...
 
Back
Top