Resource Picture Control SOLVED

[Juni]

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  

[CommonTater]

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.

[Juni]

@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.

[CommonTater]

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...

[JohnF]

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

[Juni]

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.

[JohnF]

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

[Juni]

@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

[JohnF]

I'm still not sure what you are trying to do.

This will attach a bitmap to the static control.

Code: [Select]

SendMessage(hCtrl, STM_SETIMAGE, (WPARAM)IMAGE_BITMAP, (LPARAM)hbmp);

It will automatically repaint when necessary.
 
John

[Juni]

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.

[CommonTater]

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.

[JohnF]

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

[Juni]

Thank you very much both 

The sample really helps a lot thank you 

[Juni]

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

[JohnF]

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