Painting SS_GROUPBOX background, how?
lpino
the client window that owns the box, clips the control (even with
WS_CLIPCHILDREN flag off) and prevents from invalidating the box area.
I added a WinInvalidateRect to the WM_ERASEBACKGROUND to force
repainting the whole client. This works but only so far, because there
are plenty of other situations where WM_ERASEBACKGROUND doesn't get
call and I keep getting update problems.
For instance I want to change the size of the group box in runtime in
response to a change in the controls aspect of the contained controls.
I need to be able to add the groupbox invalidated rect to the PS from
within the WM_PAINT, can it be done?
Thanks
Steven Levine
> How do I paint over the box area of a static SS_GROUPBOX?. The PS of
> the client window that owns the box, clips the control (even with
> WS_CLIPCHILDREN flag off) and prevents from invalidating the box area.
> I added a WinInvalidateRect to the WM_ERASEBACKGROUND to force
> repainting the whole client.
If I understand the docs, you are misusing the message. I believe
this message is sent by the frame window WM_PAINT handler to ask the
client what to do with the background.
A typical non-null usage is
case WM_ERASEBACKGROUND:
WinFillRect((HPS) mp1, (PRECTL) mp2, 0x00d0d0d0);
return 0;
which fills the background with an alternate color and tells the paint
routine do leave the background alone.
> I need to be able to add the groupbox invalidated rect to the PS from
> within the WM_PAINT, can it be done?
TTBOMK, you can't. What you can do is post a UM_... message and do
the work when processing this message. That said, it seems to me you
should be able to handle the size change calculations before getting
to WM_PAINT. The message names escape me at the moment, but there are
several query/calc type messages that are sent before WM_PAINT is
invoked.
Steven
--
----------------------------------------------------------------------
----------------------
Steven Levine <ste...@earthlink.bogus.net>
eCS/Warp/DIY etc. www.scoug.com www.ecomstation.com
----------------------------------------------------------------------
----------------------
lpino
wrote:
> On Tue, 15 Sep 2009 19:25:59 UTC, lpino <lp...@previred.com> wrote:
> > How do I paint over the box area of a static SS_GROUPBOX?. The PS of
> > the client window that owns the box, clips the control (even with
> > WS_CLIPCHILDREN flag off) and prevents from invalidating the box area.
> > I added a WinInvalidateRect to the WM_ERASEBACKGROUND to force
> > repainting the whole client.
>
> If I understand the docs, you are misusing the message. I believe
> this message is sent by the frame window WM_PAINT handler to ask the
> client what to do with the background.
>
> A typical non-null usage is
>
> case WM_ERASEBACKGROUND:
> WinFillRect((HPS) mp1, (PRECTL) mp2, 0x00d0d0d0);
> return 0;
>
> which fills the background with an alternate color and tells the paint
> routine do leave the background alone.
Didn't work, the RECTL coordinates are ok, the problem is that when I
call WinFillRect it doesn't honor the whole area, because it clips the
area of the groupbox that is invalidated.
>
> > I need to be able to add the groupbox invalidated rect to the PS from
> > within the WM_PAINT, can it be done?
>
> TTBOMK, you can't. What you can do is post a UM_... message and do
> the work when processing this message.
WM_PAINT message?
That said, it seems to me you
> should be able to handle the size change calculations before getting
> to WM_PAINT. The message names escape me at the moment, but there are
> several query/calc type messages that are sent before WM_PAINT is
> invoked.
I believe it's not a calculation problem but a clipping issue. The
weird thing is that when the window (client window) is totally obscure
and it's brought back to the foreground the painting works perfectly.
The problem arises when the client window it's partially covered and
then it's brought back to the foreground.
This testcase it's a frame + client window + groupbox + three
checkboxes
Thanks
Steven Levine
> Didn't work, the RECTL coordinates are ok, the problem is that when I
> call WinFillRect it doesn't honor the whole area, because it clips the
> area of the groupbox that is invalidated.
You can experiment with the WC_CLIPPARENT window style. It might do
what you need at the cost of some screen flicker.
> > TTBOMK, you can't. �What you can do is post a UM_... message and do
> > the work when processing this message.
>
> WM_PAINT message? �
If I wasn't clear, I meant you could post the private UM_... message
from WM_PAINT.
It's almost always safe to post messages from any message processing
code. What is often not safe is sending messages.
> I believe it's not a calculation problem but a clipping issue. The
> weird thing is that when the window (client window) is totally obscure
> and it's brought back to the foreground the painting works perfectly.
This might be a z-order issue. The windows are painted bottom to top,
IIRC.
Regards,
Steven
--
----------------------------------------------------------------------
lpino
wrote:
> On Wed, 16 Sep 2009 19:33:41 UTC, lpino <lp...@previred.com> wrote:
> > Didn't work, the RECTL coordinates are ok, the problem is that when I
> > call WinFillRect it doesn't honor the whole area, because it clips the
> > area of the groupbox that is invalidated.
>
> You can experiment with the WC_CLIPPARENT window style. It might do
> what you need at the cost of some screen flicker.
I will try that
> This might be a z-order issue. The windows are painted bottom to top,
> IIRC.
I'll check into this too.
I'm convinced that this is a clipping problem. I'll go and follow the
execution path from the very creation of each window to check the
state of the clipping flags, only that way I'll make sure this is or
is not the issue.
If that fails I will try to paint the background myself in the process
of the WM_PAINT in the GroupBox.
There are some details that may add some information to this problem.
- The client window process the WM_PAINT and mostly just calls
WinFillRect
- The RECTL passed to WinFillRect is correct, but using other
API's I can check the regions and the area of the group background is
not included in the list of update regions, therefore is not repainted
- There is not processing of the WM_PAINT message in the Groupbox
winproc
- The PS is reused (although I tried getting a new PS for every
call and the result was the same)
Regards and thanks
lpino
> > Didn't work, the RECTL coordinates are ok, the problem is that when I
> > call WinFillRect it doesn't honor the whole area, because it clips the
> > area of the groupbox that is invalidated.
>
> You can experiment with the WC_CLIPPARENT window style. It might do
> what you need at the cost of some screen flicker.
>
> > > the work when processing this message.
>
>
> If I wasn't clear, I meant you could post the private UM_... message
> from WM_PAINT.
>
> It's almost always safe to post messages from any message processing
> code. What is often not safe is sending messages.
>
> > I believe it's not a calculation problem but a clipping issue. The
> > weird thing is that when the window (client window) is totally obscure
> > and it's brought back to the foreground the painting works perfectly.
>
> This might be a z-order issue. The windows are painted bottom to top,
> IIRC.
>
> Regards,
>
> Steven
>
> --
> ----------------------------------------------------------------------
> -----------------
> eCS/Warp/DIY etc.www.scoug.comwww.ecomstation.com
> ----------------------------------------------------------------------
> -----------------
Problem solved. As I suspected, it was a clipping problem. I found a
wrong setting of a WS_*.
Thanks for your help