own component - painting-problem
Dirk Hennings
I derived my component from TPanel.
The only thing I "really" do is override the paint-method:
procedure TMyPanel.Paint;
begin
inherited;
bitblt(canvas.handle, 0,0, width, height, background.bitmap.canvas.handle,
0,0, SRCCOPY)
end;
I have no idea what inherited changes?
Is this needed?
A friend told me that a call to BeginPaint should be made so that the
paint-procedure isn't recursively called.
Is this true?
The main problem is that while resizing the application flickers a lot.
It seems that the Panel paints itself with its color first.
After that the picture is copied on the canvas.
I'm not really sure if this is the case, because:
I tried this on 3 other computers and no flickering at all.
My graphic-card seems to have a strange driver though (or because?) it's a
Matrox G450.
Many applications are running slowly on my computer, but if I see something
like the flickering I get suspicious!
Is it possible that my driver is buggy and I my component is totally ok?
Since the background is painted first and my background-image is copied
afterwards I thought that my component is buggy and the operation is so
simple, so that I just can't see the "bad effect" on other computers.
Does anybody know if this can be the case?
I'm not familiar with the painting of component and the integration of the
driver.
Maybe this could be the driver's fault, maybe not.
I would really appriciate any piece of information on that since I'm really
confused.
Thanks a lot
Dirk
Rob Kennedy
> I derived my component from TPanel.
> The only thing I "really" do is override the paint-method:
>
> procedure TMyPanel.Paint;
> begin
> inherited;
> bitblt(canvas.handle, 0,0, width, height, background.bitmap.canvas.handle,
> 0,0, SRCCOPY)
> end;
>
> I have no idea what inherited changes?
Do you have the source code for the VCL? You probably do. Follow the
inheritance tree to find out what the inherited paint method does. If
TPanel doesn't have a Paint method, then try TCustomPanel, and then
TCustomControl, and so on until you find the class that introduces Paint.
Another way is to set a breakpoint on the inherited line and then press
F7 to follow the execution path. Make sure you have the Debug DCUs
compiler option enabled. (When tracing through painting code, it often
helps to start the program without the breakpoint, reposition your
program's window so it does not overlap with any Delphi windows, and
then set the breakpoint. Minimize your program, and then restore it to
force a repaint. Now you can trace through the code and watch your
window get repainted step by step.)
> Is this needed?
Probably not since you're painting over the entire control.
If you're painting over the entire control, then you probably don't need
to inherit from TPanel. TPanel introduces several border-style
properties. Try setting those properties on your own component, and if
you can't see any changes, then TPanel isn't right for you. Use
TCustomControl instead. It provides a convas, but doesn't offer any
other bells or whistles.
If your painting routine is hiding the border, but you *want* the
border-style properties in your own control, then you need to account
for the border size and client area when you paint your control. Look at
TCustomPanel.Paint to see how it's done.
> A friend told me that a call to BeginPaint should be made so that the
> paint-procedure isn't recursively called.
> Is this true?
Absolutely not. BeginPaint should be called once and only once,
inresponse to a wm_Paint message. TCustomControl already catches that
message for you, calls BeginPaint, sets the canvas's device-context
handle (DC), and calls your control's Paint method.
> The main problem is that while resizing the application flickers a lot.
> It seems that the Panel paints itself with its color first.
That would be the inherited call in action. You can also reduce flicker
by setting the control's DoubleBuffered property to True.
An essential resource when writing components is the VCL source code.
It's nearly impossible to write a component without access to it. The
help files don't give you the information you need to make intelligently
written components. There are many control messages that get passed
around, and there are many protected methods that get called, and for
the most part, they aren't documented, so you need to learn by example,
seeing who calls what when, and what arguments are passed.
--
Rob
J French
wrote:
>Hi,
>
>I derived my component from TPanel.
>The only thing I "really" do is override the paint-method:
>
>procedure TMyPanel.Paint;
>begin
>inherited;
>bitblt(canvas.handle, 0,0, width, height, background.bitmap.canvas.handle,
>0,0, SRCCOPY)
>end;
>
>I have no idea what inherited changes?
Inherited ultimately calls the code in ExtCtrls.TCustomPanel.Paint
>Is this needed?
In this case almost certainly not
>A friend told me that a call to BeginPaint should be made so that the
>paint-procedure isn't recursively called.
It does not seem to have much to do with recursion
Anyway recusion should not happen if you do not have an
Application.ProcessMessages in your Paint procedure
>Is this true?
I think not
>The main problem is that while resizing the application flickers a lot.
>It seems that the Panel paints itself with its color first.
>After that the picture is copied on the canvas.
I think Rob Kennedy answered that one very comprehensively
>I'm not really sure if this is the case, because:
>I tried this on 3 other computers and no flickering at all.
>My graphic-card seems to have a strange driver though (or because?) it's a
>Matrox G450.
>Many applications are running slowly on my computer, but if I see something
>like the flickering I get suspicious!
So do I - mainly about my own code
>Is it possible that my driver is buggy and I my component is totally ok?
It sounds as if your Graphics driver is not highly optimized and
intelligent - which is ideal for a development machine
>Since the background is painted first and my background-image is copied
>afterwards I thought that my component is buggy and the operation is so
>simple, so that I just can't see the "bad effect" on other computers.
Some Graphics Drivers and Cards eliminate flickering, making slightly
faulty code look good
>Does anybody know if this can be the case?
>I'm not familiar with the painting of component and the integration of the
>driver.
>Maybe this could be the driver's fault, maybe not.
My money is on your driver being Ok
>I would really appriciate any piece of information on that since I'm really
>confused.
What version of Delphi do you have ?
Is it a Pro or Enterprize version ?
With those you get the source of the VCL libraries, which you can
drill into to find out what is happening.
For example I have just traced back the ancestry of the TPanel's Paint
method into ExtCtrls.TCustomPanel.Paint
It does a lot of faffing around with drawing Bevels, then it does a
FillRect on the interior area, then it prints the Panel's caption
None of which are of the remotest interest to your Control
HTH