Pelles C forum
C language => Windows questions => Topic started by: Juni on September 02, 2010, 06:26:08 PM
-
Hello Forum,
i use multiple picture controls in ressource editor,
wich gets a bit confusing to handle by WM_PAINT.
I wonder about some things:
1. what class is that control ?
2. does it have a buffer wich i can access ?
3. how come that i can draw outside its boundaries ?
Thank you :)
-
You don't need to handle WM_PAINT.
That is a system signal to redraw invalidated parts of the display.
And yes you can --but shouldn't-- draw outside the lines.
-
@CommonTater hi, thank you :)
Most sources i tried wrote their drawing code in a WM_PAINT handler,
so where else should i do that ?
I want to use Picture control like in VB or Delphi,
in both IDEs i could do like "buton_onclick -> draw to control"
but it seems without a buffer thats impossible ?
Same for boundaries,
is the only way to reach "auto"-boundaries
to use a buffer and blit only the "allowed" region ?
(Or create a child window, embedd picture control.. what is that control good for then ?)
Thank you.
-
Ok, I'm not highly experienced with graphic drawing. My big foret into that was a custom control I wrote about 3 or 4 years ago. So I will defer to one of the others who can probably give you much better graphic drawing advice than I could...
But do keep in mind that windows messages are intercepted only with the greatest of caution. For example: Intercepting a WM_PAINT that is not for your control, might result in the dialog not being repainted at all... Wait till you see that! What a mess...
-
Hello Forum,
i use multiple picture controls in ressource editor,
wich gets a bit confusing to handle by WM_PAINT.
I wonder about some things:
1. what class is that control ?
2. does it have a buffer wich i can access ?
3. how come that i can draw outside its boundaries ?
Thank you :)
The class is a 'static' control that uses 'SS_BITMAP' as part of its style.
You can subclass any windows control - this gives you almost complete control over it. If you mess with it the disadvantage is you will probably have to draw the picture yourself for any WM_PAINT that comes along.
John
-
Thank you both for your answer :)
Those keywords sound a bit clearer,
googling for "picture control" was like ... ><
At the moment all my code is in WM_PAINT
and it gets "configured" by (to many) globals.
Subclassing sounds good.
But if i understand correct
i would still have to manage how functions can directly draw to those subclassed pictures ?
Is there any alternate to double-buffering ?
Thank you.
-
But if i understand correct
i would still have to manage how functions can directly draw to those subclassed pictures ?
Is there any alternate to double-buffering ?
Thank you.
You would draw the pictures in WM_PAINT within the subclass function. You may be able to deal with all the picture box controls in one subclass function by using GetDlgCtrlID() API. This would tell you which control is sending the message, i.e. WM_PAINT.
I'm not sure what you mean by double buffering in this context. Windows has the bitmap handle and uses it to blit the picture onto the control.
EDIT:
If you mean that you are modifying the bitmap, well, you have to draw to the bitmap itself before blit-ing to the picture box.
This is achieved by creating a DC, select the bitmap into that, do some work, then use the altered bitmap.
John
-
@JohnF hi thank you :)
For now i was accessing control direct
by BeginPaint in WM_PAINT (dunno if a bitmap is involved).
Other Demos in www used such a invisble HBITMAP to prevent flickering
and called it "double buffering"
thats why i came up with idea to handel it in the background.
By "modifying" i meant "draw from any function".
i.e. i create a button, give it handle of Picture Control
and a "drawline" would be send internal
and WM_PAINt would handle it internal.
Delphi and VB both work that way.
If you got lot picture controls
and even more buttons wich access them
it really is much easier.
(but performance breakdown with even low amount objects)
I will try subclass the static and attach a HBITMAP
or does it already exist ?
Thanks a lot :)
-
I'm still not sure what you are trying to do.
This will attach a bitmap to the static control.
SendMessage(hCtrl, STM_SETIMAGE, (WPARAM)IMAGE_BITMAP, (LPARAM)hbmp);
It will automatically repaint when necessary.
John
-
I'm still not sure what you are trying to do.
I´m trying to separate code a bit.
Atm i have like lets say 4 picture boxes
and 5 buttons.
Each button change one or more pictures.
Picture shall not be erased,
the change shall be added.
My Code looks awfull for now,
the buttons only set some vars
and all drawing for all pictures
is handled in 1 large WM_PAINT part.
In VB and Delphi it works different.
If i write "button1_onclick .. add a line to graphic"
then its a separate function "button1_onclick"
and if i have to find a bug
i can simply click that function.
(no WM_PAINT involved)
Also,
my code didn´t involve any bitmap for now.
Everything was drawn directly to picture controls.
(it is flickerfree but the code looks awfull)
My only question now is,
if i use Dialog-Editor and put lets say 5 picture controls,
can i change (subclass) them afterwards,
or does subclassing mean i have to put controls by code into dialog ?
Thank you :)
I attached demo to show you what i meant.
-
Juni... I do hope you don't mind if I jump back in here for just a sec....
Just a bit of friendly advice if I may... Don't compare C to Delphi, learn it as a completely separate experience. OOP and Procedural programming are totally different mindsets and about the only way to avoid confusion is to keep them that way.
A few of the differences are important...
Delphi does everything by forms and visual setup. In C it's all code... Which means that C is much more intimate with the OS than Delphi... heck you can almost smell the CPU registers in C.
Delphi being a pascal derivative has a ton of built in type and range checking that is almost completely absent in C... While C will prevent typecasts between variables of different sizes, the rest is up to you. This gives you more control, but it also breeds superior screwups so care must be exercised.
Finally... Pascal compilers almost run the programs as they compile, they will warn you about a lot of stuff that C will not. For example, the Delphi compiler will tell you about overflows and buffer overruns but the C compiler does not.
All this boils down to C programmers having far more power at their fingertips... but it also requires that different mindset I spoke of... JohnF is an excellent programmer, I learned a lot studying his code. You would do well to study the way C programmers work... it's not without reason.
-
Juni,
The attached project shows how to subclass.
EDIT: Changed it so that the picture box will be redrawn if covered and uncovered by another window.
John
-
Thank you very much both :)
The sample really helps a lot thank you :) :)
-
Hello :)
Sry to ask again but
trying to find out the difference since 2 days..
1.
In situation when window was hidden,
wich line force your demo to redraw ??
2.
In your demo the header contains a line
"Header file generated by Pelles-C"
..is there a way to autogenerate a header by a ressource ??
Thank you very much :)
-
Hello :)
Sry to ask again but
trying to find out the difference since 2 days..
1.
In situation when window was hidden,
wich line force your demo to redraw ??
2.
In your demo the header contains a line
"Header file generated by Pelles-C"
..is there a way to autogenerate a header by a ressource ??
Thank you very much :)
1. The picture control will automatically receive a WM_PAINT.
2. When you use the project Wizard the header will be produced by PellesC.
John
-
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 :D
Thank you very much :)
-
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.
if (!bCapture)
return; // No need to redraw if not in capture mode
John
-
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 :)
-
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
-
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...)
-
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.
#define UpdateNow(hwnd) InvalidateRect(hwnd, NULL, TRUE); \
UpdateWindow(hwnd)
John
-
Thanks John... that's exactly what I was getting at.
-
Thank you both i really appreciate all your help :)