Re: [MiNT] Window with toolbar and redraw messages

[Jean-François Lemaire <jflemaire@skynet.be>]

On Sunday 01 December 2013 21:02:35 Helmut Karlowski wrote:
> Jean-François Lemaire, 01.12.2013 19:40:01:
> > As an example, suppose you have inside a toolbar a box with some
> > scrollable
> > text drawn via the VDI. Each time you click the arrows you receive a
> > message
> > so you can scroll the text. But when the text must be redrawn for some
> > other
> > reason, the window never receives a WM_REDRAW message so you can't
> > update the
> > text.
> 
> What other reason?

The window is moved out of the desktop then back within it so the AES can't 
just blit it. Or the window is enlarged and the text needs to be adapted.

Basically, I'm describing toolbars with an "embedded" work area, if that makes 
sense.

> Is your prg informed of that?

That's the point. As far as I can see the program never receives a redraw 
message for windows made up *only* of a toolbar. I guess from the point of 
view of the AES there's no reason to since there's no work area.

> > I suspect there is no other way around a G_USERDEF in those cases.
> 
> I don't like that. But I'm currently no expert for toolbars.

I was thinking that maybe a wind_set() mode to ask that a specific window 
should receive WM_REDRAW messages *every* time it is redrawn (even by the AES) 
would be useful.

For example, currently making windows with several toolbars is a pain, because 
only one is handled by the AES. You need to handle the others yourself. The 
ability to create a large toolbar with a "white box in the center" which would 
serve as a work area would provide the capability to position GEM objects 
either on the top, the sides, the bottom...

If such windows could receive WM_REDRAW messages, the app would only have to 
compare the coordinates received with those of the "white box" and redraw that 
area only.

Maybe it's a stupid idea?

Cheers,
JFL
-- 
Jean-François Lemaire