1. getClientRect
In the doc it says
getClientRect ( integer ControlId )
Get uncovered portion of the client area.
Returns: { x1, y1, x2, y2 }
If I not mistaken, it should be
{x, y, width, height} ??
Thanks!
2. Re: getClientRect
----- Original Message -----
From: "aku saya" <akusaya at gmx.net>
To: "EUforum" <EUforum at topica.com>
Subject: getClientRect
>
> In the doc it says
>
> getClientRect ( integer ControlId )
> Get uncovered portion of the client area.
> Returns: { x1, y1, x2, y2 }
>
> If I not mistaken, it should be
> {x, y, width, height} ??
>
Actually that turns out not to be the case. This routine returns {Left, Top,
Right, Bottom} coordinates. Not the way I'd do it but that's Windows for
you.
Actually, I'll enhance the return value so it returns {Left, Top, Right,
Bottom, Width, Height}.
----------------
cheers,
Derek Parnell
3. Re: getClientRect
> > getClientRect ( integer ControlId )
> > Get uncovered portion of the client area.
> > Returns: { x1, y1, x2, y2 }
> >
> > If I not mistaken, it should be
> > {x, y, width, height} ??
> >
>
> Actually that turns out not to be the case. This routine returns {Left,
Top,
> Right, Bottom} coordinates. Not the way I'd do it but that's Windows for
> you.
>
> Actually, I'll enhance the return value so it returns {Left, Top, Right,
> Bottom, Width, Height}.
Isn't that redundant? Why not make the user figure the Width and Height? I
know it's very very few cycles to do the calculation in the library, but
redundancy or duplicity doesn't seem right to me. :)
I'm just wondering what your reasoning was... not complaining!!!
4. Re: getClientRect
----- Original Message -----
From: "C. K. Lester" <cklester at yahoo.com>
To: "EUforum" <EUforum at topica.com>
Subject: Re: getClientRect
>
> > > getClientRect ( integer ControlId )
> > > Get uncovered portion of the client area.
> > > Returns: { x1, y1, x2, y2 }
> > >
> > > If I not mistaken, it should be
> > > {x, y, width, height} ??
> > >
> >
> > Actually that turns out not to be the case. This routine returns {Left,
> Top,
> > Right, Bottom} coordinates. Not the way I'd do it but that's Windows for
> > you.
> >
> > Actually, I'll enhance the return value so it returns {Left, Top, Right,
> > Bottom, Width, Height}.
>
> Isn't that redundant? Why not make the user figure the Width and Height? I
> know it's very very few cycles to do the calculation in the library, but
> redundancy or duplicity doesn't seem right to me. :)
>
> I'm just wondering what your reasoning was... not complaining!!!
Sure! Nearly every use of getClientRect() is done to get the dimensions of
the client area rather than the coordinates of the bottom-right corner. This
means that people are generally doing this sort of thing...
r = getClientRect(x)
w = r[3]-r[1]
h = r[4]-r[2]
. . .
So all I'm doing now is doing these two subtractions for the caller. As you
say, it is a tiny use of the computing cycles available but it reduces that
amount of code to maintain in your program.
Win32lib is doing many redundant things, depending on your criteria. But
that is the very point of its existance. It does these things to make coding
you application easier. It is not trying to make your program run as fast as
it possibly can. The library is not about "making the user do ...", instead
it tries to do things so the user doesn't have to.
----------------
cheers,
Derek Parnell
5. Re: getClientRect
----- Original Message -----
From: "Al Getz" <Xaxo at aol.com>
To: "EUforum" <EUforum at topica.com>
Subject: RE: getClientRect
>
>
> Hello Derek, CK, and aku,
>
>
> GetClientRect
>
> is named
>
> "GetClientRect"
>
> because it's made to
> "Get"
> the
> "Client"
> "Rect"
>
> This means what it is to retrieve is very specific:
> the "Client Rect".
>
> The "Rect" is a predefined structure in Windows,
> which is made up of four consecutive values of
> type LONG which can be any values.
>
> The "Client Rect" however is a little different.
> It's still made up of three type LONG's, but the
> first two are always zero.
>
> The usual reason you want to get this RECT
> is so that you can pass it to another function
> which takes the type RECT, such as FillRect().
>
> What's particularly interesting about this
> structure after a function call to
> "GetClientRect" though is that
> the first two LONG's are always zero
> because the Rect is referrenced to the
> upper left corner, which is (0,0).
> This means after the function returns,
> the RECT structure contains:
> [
> 0
> 0
> ClientsWidth
> ClientsHeight
> ]
>
> which in a Euphoria sequence might look like this:
>
> atom ClientsWidth,ClientsHeight
> sequence Rect
> constant zero=0
> ClientsWidth=600
> ClientsHeight=400
> Rect={zero,zero,ClientsWidth,ClientsHeight}
>
> Notice the Rect already contains the Clients Width and Height.
> If the library function call simply peeks the values
> the returned sequence should contain the width and height
> without doing a subtraction.
>
Thanks for the backgrounder. However win32lib does a slight modification of
this, namely that any toolbar and any statusbar are excluded from the
'client'' area. Thus it is possible for Win32lib's getClientRect to return
non-zero values for the second element of the 'rect' data. And in some
future version of the library, when it supports vertical toolbars, the first
element might also be non-zero.
----------------
cheers,
Derek Parnell
