[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [MiNT] usage of wind_calc()



Hello,

Sorry for quoting the whole post, but this is needed :/

On Tue, 05 Jul 2005 04:30:06 +0200, <evan@coolrunningconcepts.com> wrote:

Quoting Arnaud BERCEGEAY <arnaud.bercegeay@free.fr>:

Wait - why is ANY of this needed.

because wind_get(WF_WORKXYWH) is buggy in some AESes : with buggy AES,
wind_get(WF_WORKXYWH) forget to take into account the height of the
toolbar.

The method in windom works for all AESes.

Who cares about the toolbar? When you merge the area to be redrawn with each rectangle of the rectangle list for the window, the toolbar shouldn't matter at all. The toolbar isn't included in the rectangle list for the window is it?

If so, I would think what you need is the size of the toolbar, and the sizes of
the window widgets shouldn't matter.   What am I missing?

I though we all agreed on this subject, and the discussion was over on
this subject.

Sorry - I still don't understand the problem.

However, why do you need WORKXYWH to handle a redraw?  You are given a
rectangle that needs to be redrawn, which shouldn't be outside the
working area of the window, but even if it is, when you walk the
rectangle list and merge those rectangles with the area to be redrawn,
you won't ever get a rectangle outside the working area.  When do you
need to know WORKXYWH for a redraw?

Well, at least to know the where is the top left corner of the work area
(the origine of the drawing for the window).

The redraw message doesn't always concern the whole work area.

Why do you need to know the top left corner of the work area? You don't need to redraw the whole work area - only the area that is in the redraw message.

have you ever wrote a GEM application ?

ok, let's take an example. A text viewer.

The top left corner of the WORK area is x=50 y=200.

The first line of text is displayed by using
v_gtext( vdihandle, 50, 220, line[0]); /* 220 = 200 + height of the text */

the 2nd line of text is displayed by v_gtext(vdihandle, 50, 240, line[1]), and so on...

Now, the text editor receive a WM_REDRAW message to redraw the bottom of its WORK area, lets say
WM_REDRAW with x=50, y=500, width=400 height=50

With such message, what is the line to display at y=500 (the area to be redrawn) ? It's evident that we NEED to have the origin of the WORK area (x=50, y=200).

I hope you get it now.

Now, about the toolbar : the same window with the same work area have a toolbar at x=50, y=150 with height=50.

Sum-up: toolbar from y=150 to y=199; work area from y=200 to y=500+

With buggy AES, wind_get(WF_WORKXYWH) returns the area from y=150 to 500+, which include the area where the AES toolbar is drawn (this is the bug). If application get the WORK area that way, the first line of text will be displayed at y=70 (50+20). If the WM_REDRAW message is correct (do not contain the toolbar area), then the 3 first lines of text will never be displayed by the application (text hidden by the toolbar).

Hope it clearer now... If so, please read again the quote.

best regards,
Arnaud.