Windows Message problems on Today Screen Plugin

I've having some trouble with windows messages, as in which ones to intercept
and call for an invalidaterect.

With my plugin visible I can pop up a message box and position it over my
plugin briefly. When I remove the box, the plugin beneath it is a bunch of
gobbelty gook.

If I then select/deselect or navigate through the plugin's area if refreshes
normally.

I did notice that when I intercepted the WM_WINDOWPOSCHANGED message, this
would not happen. Unfortunately, it would redraw me any time I navigated
around on the screen.

I've got a bug somewhere in my redraw code for my icon and text that's
causing the screen to flash even though I'm using double buffering. So this
particular issue is troublesome. I'm sure I can figure out the problem with
my double buffering but I'm a little confused on the windows message
interception thing.

Does anyone have any advice on how to tell when my plugin has been uncovered
so I can tell it to repaint itself properly? Or could it perhaps something in
the way I'm painting my background/watermark? I can give more details as
needed. I'm just not sure what to show first.

I think once I get this thing fully functional I'm going to rip out the
company specific stuff in it and post it as a full example of how to handle
today plugins. Every tutorial and sample code i've been finding gives me only
a little bit. Bits and pieces and then I have to continue digging for each
new case that comes up ( like with the plugin being covered by a message box
). Hopefully I can help save somebody a few steps.

Thanks,

Ed

Scott
Thu Dec 06 14:13:58 PST 2007

=?Utf-8?B?RWQgS3JhbWVy?= <EdKramer@discussions.microsoft.com> wrote:
>
>I've having some trouble with windows messages, as in which ones to intercept
>and call for an invalidaterect.
>
>With my plugin visible I can pop up a message box and position it over my
>plugin briefly. When I remove the box, the plugin beneath it is a bunch of
>gobbelty gook.

This is a sign that your WM_PAINT handler is broken. If it's not
firing, then you won't paint (and bits of the message box will remain
behind). If it's firing and failing somehow, you can end up painting
random sections to the screen.

In short, there's nothing special you need to do for the messagebox,
your WM_PAINT handler just needs to paint when it's called.

--
--------- Scott Seligman <scott at <firstname> and michelle dot net> ---------
The beginning is the most important part of the work.
-- The Republic by Plato

EdKramer
Thu Dec 06 18:54:00 PST 2007

Broken?

Are you referring to the actual call back or the code that it calls when it
is painting? Might also explain the flashing. I'm doing double buffering, but
it's still flashing which is driving me up a wall.

"Scott Seligman" wrote:

> =?Utf-8?B?RWQgS3JhbWVy?= <EdKramer@discussions.microsoft.com> wrote:
> >
> >I've having some trouble with windows messages, as in which ones to intercept
> >and call for an invalidaterect.
> >
> >With my plugin visible I can pop up a message box and position it over my
> >plugin briefly. When I remove the box, the plugin beneath it is a bunch of
> >gobbelty gook.
>
> This is a sign that your WM_PAINT handler is broken. If it's not
> firing, then you won't paint (and bits of the message box will remain
> behind). If it's firing and failing somehow, you can end up painting
> random sections to the screen.
>
> In short, there's nothing special you need to do for the messagebox,
> your WM_PAINT handler just needs to paint when it's called.
>
> --
> --------- Scott Seligman <scott at <firstname> and michelle dot net> ---------
> The beginning is the most important part of the work.
> -- The Republic by Plato
>

EdKramer
Thu Dec 06 19:58:00 PST 2007

I'm in the process of dissecting my text writing routine. As far as I can
tell it's correct. Yet it flashes and I see the spoo when it is uncovered.
Any idea what's wrong with it? I removed a lot of the extraneous code, trying
to figure out what the problem was, but thus far I'm not having much luck.

The originalDC is the HDC passed back by my BeginPaint() call in WM_PAINT,
the PaintStruct comes from the same call.

void ScreenHandler::NewDrawText( HDC originalDC, PAINTSTRUCT* paintStruct,
WCHAR* message, int cbMessage, int bitmapWidth )
{
int width = paintStruct->rcPaint.right - paintStruct->rcPaint.left;
int height = paintStruct->rcPaint.bottom - paintStruct->rcPaint.top;
int xPosition = bitmapWidth;

COLORREF blackColor = RGB(0,0,0);
COLORREF whiteColor = RGB(255,255,255);

HDC memoryDC = CreateCompatibleDC( originalDC );
HBITMAP memoryBitmap = CreateCompatibleBitmap( originalDC, width, height );
HGDIOBJ selectedBitmap = SelectObject( memoryDC, memoryBitmap );
HBRUSH hBrush = CreateSolidBrush( blackColor );
HGDIOBJ selectedBrush = SelectObject( memoryDC, hBrush );

SetBkMode( memoryDC, TRANSPARENT );
SetBkColor( memoryDC, blackColor );
SetTextColor( memoryDC, whiteColor );

RECT rect;
rect.top = paintStruct->rcPaint.top;
rect.left = paintStruct->rcPaint.left;
rect.right = paintStruct->rcPaint.right;
rect.bottom = paintStruct->rcPaint.bottom;

FillRect( memoryDC, &rect, hBrush );

DrawText( memoryDC, message, cbMessage -1, &paintStruct->rcPaint, DT_VCENTER
| DT_NOCLIP | DT_SINGLELINE );

// TransparentBlt( originalDC, xPosition, 0, width, height, memoryDC, 0, 0,
width, height, blackColor );
BitBlt( originalDC, xPosition, 0, width, height, memoryDC, 0, 0, SRCCOPY );

SelectObject( memoryDC, selectedBrush );
DeleteObject( selectedBrush );

SelectObject( memoryDC, selectedBitmap );
DeleteObject( selectedBitmap );

}

Scott
Thu Dec 06 23:18:49 PST 2007

=?Utf-8?B?RWQgS3JhbWVy?= <EdKramer@discussions.microsoft.com> wrote:
>
>I'm in the process of dissecting my text writing routine. As far as I can
>tell it's correct. Yet it flashes and I see the spoo when it is uncovered.
>Any idea what's wrong with it? I removed a lot of the extraneous code, trying
>to figure out what the problem was, but thus far I'm not having much luck.
>
>The originalDC is the HDC passed back by my BeginPaint() call in WM_PAINT,
>the PaintStruct comes from the same call.
>
>void ScreenHandler::NewDrawText( HDC originalDC, PAINTSTRUCT* paintStruct,
>WCHAR* message, int cbMessage, int bitmapWidth )
>{
>int width = paintStruct->rcPaint.right - paintStruct->rcPaint.left;
>int height = paintStruct->rcPaint.bottom - paintStruct->rcPaint.top;

This is a fundamental problem with your design. You're creating a bitmap
potentially smaller than the entire window, yet later on you draw into
it at offsets as if it's sized to the window.

>rect.top = paintStruct->rcPaint.top;
>rect.left = paintStruct->rcPaint.left;
>rect.right = paintStruct->rcPaint.right;
>rect.bottom = paintStruct->rcPaint.bottom;
>
>FillRect( memoryDC, &rect, hBrush );
>
>DrawText( memoryDC, message, cbMessage -1, &paintStruct->rcPaint, DT_VCENTER
>| DT_NOCLIP | DT_SINGLELINE );

Let's say the paintStruct tells you to draw at 10,10-20,20. You'd create
a bitmap 10x10 big, and then draw from points 10,10-20,20 in that bitmap
10x10 bitmap, or off the edges of it. This would absolutely cause random
goo to end up on the screen since you're effectively never drawing on
your newly created bitmap.

rcPaint isn't the size of the window, it's the clipping area for what
you want to draw. It can be anything from the size of the window to one
pixel that needs to be drawn.

>BitBlt( originalDC, xPosition, 0, width, height, memoryDC, 0, 0, SRCCOPY );

Even assuming you drew the right thing above, you're bitblting it to
xPosition, which given the variable names, suggests your bitblting the
result off screen.

Given the complexity of modifying drawing code to handle clipping
regions, I'd recommend creating a bitmap of the size of your window (and
potentially keeping it around for longer than the WM_PAINT lifespan).
You can draw over the entire bitmap, and only bitblt in the portion
specified by the rcPaint rectangle.

--
--------- Scott Seligman <scott at <firstname> and michelle dot net> ---------
One more day before the storm, at the barricades of freedom! When our
ranks begin to form, will you take your place with me?
-- Enjolras in Les Miserables

EdKramer
Fri Dec 07 07:20:02 PST 2007


> Even assuming you drew the right thing above, you're bitblting it to
> xPosition, which given the variable names, suggests your bitblting the
> result off screen.

Well the xPosition was basically just to make sure the text got drawn to a
position that was far enough to the right that it wouldn't be over or under
the icon i'll be drawing. But yeah I see what you mean.


> Given the complexity of modifying drawing code to handle clipping
> regions, I'd recommend creating a bitmap of the size of your window (and
> potentially keeping it around for longer than the WM_PAINT lifespan).
> You can draw over the entire bitmap, and only bitblt in the portion
> specified by the rcPaint rectangle.
>

I'm thinking this is probably the best idea. Create the memory DC once at
startup and destroy it when I shut down.

If the orientation changes, i get a WM_SIZE event, but how do I resize my
memory bitmap?

Or should I just make it some arbitrarily large size ( which could be
potentially too small or way to big ), and only use the portion that the
WM_PAINT tells me is the correct one?

I thought I was getting the hang of GDI, but it seems like every time I
think I have an idea what I'm doing it kicks me in the teeth. Oh well. I feel
like I'm back in Programming 201 =)

Thank you for the assistance by the way. I feel like I've been bashing my
face against this forever. Any help is appreciated.

Ed

ctacke/>
Fri Dec 07 07:31:23 PST 2007

> I'm thinking this is probably the best idea. Create the memory DC once at
> startup and destroy it when I shut down.
>
> If the orientation changes, i get a WM_SIZE event, but how do I resize my
> memory bitmap?

Make the DC the size of the screen (query the device to get that). If the
orientation changes, toss away the existing DC and create another with the x
& y sizes flipped.

If you expect that rotation will happen a lot you could create both DCs to
start with and simply swap pointers when rotation happens, but that uses
twice the memory and I doubt it gains much in performance.

--

Chris Tacke, eMVP
Join the Embedded Developer Community
http://community.opennetcf.com