Resource Picture Control SOLVED

[Juni]

1. The picture control will automatically receive a WM_PAINT.

Weird thing is in my first demo it didn t receive it,
so i assume it works in your demo because of subclassing ?

2. When you use the project Wizard the header will be produced by PellesC.

Oh ok thank you very much,
thought there might be a hidden helper wich produce header by ressource

Thank you very much

[JohnF]

1. The picture control will automatically receive a WM_PAINT.

Weird thing is in my first demo it didn t receive it,
so i assume it works in your demo because of subclassing ?

Yes, subclassing allows us to directly get the controls messages.

Your first demo was not dealing with the WM_PAINT of the picture box, it was dealing with the WM_PAINT of the main dialog box.

All controls are windows and as such, receive messages in the same way as a application window. This is why/how one can subclass them as shown in my example and choose to react to any of the messages one needs to.

EDIT: Also you have this in the paint proc.

Code: [Select]

if (!bCapture)
return; // No need to redraw if not in capture mode

John

[Juni]

Hi thank you

Yes i removed that check but the message still got lost,
i think now somehwere in parents window message qeue
there must be kinda check not to repaint that static.

Thanks a lot for all the help

[JohnF]

Hi thank you

Yes i removed that check but the message still got lost,
i think now somehwere in parents window message qeue
there must be kinda check not to repaint that static.

Thanks a lot for all the help

You were not looking at the picture box messages, this is important. Each window (control) has its own message-ing so only by having a control subclassed can one deal with messages specific to that control.

There could easily be a situation where the dialog would receive a WM_PAINT and picture box would not, or the other way around.

EDIT:
I'll put it a different way: when the dialog receives a WM_PAINT, that does not mean that the picture box also needs one. When the picture box gets a WM_PAINT it does not mean the dialog will get a WM_PAINT.

John

[CommonTater]

Hi, John...

Perhaps a better way to explain is that WM_PAINT is only issued under very specific conditions... Such as when a window is created, moved, resized, occluded, clipped, etc.  Merely drawing to a control does not bring a WM_PAINT because it is reasonable to assume that drawing on a control is the act of bringing it up to date.

It should also be noted that in many cases WM_PAINT is deferred in favor of higher prioity messages so that window updates may not occur instantaneously in a window with busy message traffic.  I don't know if you've ever seen it, but there was once some source code using SetTimer that kept a program so busy it's windows never redrew themselves...

If Juni needs redraws, he's probably much further ahead to call his redrawing function directly in code after making changes than to wait for WM_PAINT to come along. (Yet another reason not to put code in switch statements...)

[JohnF]

Hi, John...

Perhaps a better way to explain is that WM_PAINT is only issued under very specific conditions... Such as when a window is created, moved, resized, occluded, clipped, etc.  Merely drawing to a control does not bring a WM_PAINT because it is reasonable to assume that drawing on a control is the act of bringing it up to date.

He hopefully already understand those issues.

If Juni needs redraws, he's probably much further ahead to call his redrawing function directly in code after making changes than to wait for WM_PAINT to come along. (Yet another reason not to put code in switch statements...)

Well, responding to a WM_PAINT is good because update regions are already in place governed by windows - which means not all the area has to be repainted every time - which is controlled by clipping, which in turn means the drawing can be much quicker. Certainly with some apps drawing outside a WM_PAINT is essential, e.g. DirectX stuff or a constantly changing image, but for ordinary apps responding to the PAINT message is best as one only needs to draw at that time.

For bypassing the message queue you can use InvalidateRect() followed by an UpdateWindow() to make it immediate.

Code: [Select]

#define UpdateNow(hwnd)  InvalidateRect(hwnd, NULL, TRUE); \
                            UpdateWindow(hwnd)


John

[CommonTater]

Thanks John... that's exactly what I was getting at.

[Juni]

Thank you both i really appreciate all your help