GETSIZE/SETSIZE - Understanding how it works at present.

[LarryMc]

If you have used EBasic(or IBasic) for any amount of time you have probably used SETSIZE to move a window/dialog/or control. You may or may not have used the GETSIZE command.

From the help file:

SETSIZE(win as WINDOW, l as UINT, t as UINT, w as UINT, h as UINT, OPT id=0 as UINT)

Description
Sets the size of a window, dialog or control.

Parameters
win - Window or dialog.
l, t, w, h - New position and dimensions.
id - Optional control identifier.

Return value
None.

Remarks
See Also: GETSIZE

Example usage
SETSIZE mywindow, 0, 0, 100, 250

and

GETSIZE

GETSIZE(win as WINDOW, l as INT BYREF,t as INT BYREF,w as INT BYREF,h as INT BYREF,OPT id=0 as UINT)

Description
Gets the size of a window, dialog or control. The dimensions returned include the borders and caption.

Parameters
win - [in] Window or dialog
l, t, w, h - [out] Variables to receive the dimensions
id - [in] Optional control identifier.

Return value
None

Remarks
Variables must be of type INT. Coordinates are returned relative to the screen.

See Also: SETSIZE

Example usage
DEF l,t,w,h  as INT
GETSIZE mywindow, l, t, w, h

First, let's just focus on windows and dialogs.

When you create a window or a dialog you pass to the command, among other things,:
   l  -  the x-pos on the screen of the left side of the window/dialog relative to the top left corner of the screen (0,0)
   t -  the y-pos on the screen of the top side of the window/dialog relative to the top left corner of the screen (0,0)
   w-  the width of the window/dialog
   h -  the height of the window/dialog
From these 4 values the 4 corners of rectangle that encloses everything in the  window/dialog is determined.  This rectangle is referred to as the "windowrectangle".  And all numbers are in pixels.

so a window/dialog that is created as 0,0,100,200 will have it's corners at
   top-left    0,0           top-right    100,0
   bot-left    0,200        bot-right    100,200

if we had created the window/dialog with 50,20,100,200 we would have corners at
   top-left   50,20           top-right    150,20
   bot-left   50,220         bot-right    150,220

No rocket science there.

Next, logic would dictate if I had created the 2 window/dialogs above and then use GETSIZE to retrieve
l,t,w,and h that I would wind up with the same numbers.  And that's exactly what happens when dealing with windows and dialogs.

You could write a program that creates a window/dialog then goes into a loop where it performs a GETSIZE and with the returned values does a SETSIZE and the window would never move.  Are more accurately it would continue to be moved each time to exactly where it already is.  And that is what you would expect.

Remember the "windowrectangle" from above that goes around everything in a window or dialog.  There's another rectangle, "clientrectangle" which resides totally inside the "windowrectangle".  It's size is determined by taking the "windowrectangle" and subtracting space taken up by such things as window borders, caption bars, menu bars, vertical and horizonal scroll bars, and status bars.

When you add a control (button,edit,listbox,etc) you enter l,t,w,and h values for each control just as you did when you created the dialog or window.
The w and h values can be defined exactly the way they were for the win/dlg, ie. the width and height of the control.

Here's where the "gottcha" starts.
In the win/dlg creation l and t were measured from the top left corner of the screen.
In a control l and t are measured from the top left corner of the parent win/dlg's "clientrectangle".

As an example let's use the window/dialog with 50,20,100,200 we had before.
If we wanted a button 10 pixels down and to the right of the client area of the window we would create the button
with 10,10,50,20 (50 pixels wide and 20 pixels height)

2nd part of "gotcha"
The help file says that GETSIZE and SETSIZE can be used for controls, which is true.

If I create the win/dlg with 50,20,100,200 and the button with 10,10,50,10 and use GETSIZE on the button I will never get l and t with a 10,10,50,10 unless I created the win/dia with no caption,no menu,no border.
If the window has just a caption I'll get 63,53,50,10 because GETSIZE returns l and t based upon offset from the top left corner of the screen.
so for the button its 50(from the "windowrectangle")+ 3 for the left border+10 for the button offset from the "clientrectangle" left edge for a total of 63.
for the t I get 20(from the "windowrectangle"+23from the caption+10 for the button offset from the "clientrectangle" top edge for a total of 53.

The final part of the "gottcha"
Remember that with win/dlg you could take what was obtained with GETSIZE and plug it into SETSIZE and the win/dlg wouldn't move because both were using numbers relative to the top left corner of the screen.
It you do that loop thing with a control (GETSIZE/SETSIZE like we did above) the control want stay in one spot; with each iteration the control will move down and to the left.

That's because for controls GETSIZE is using screen coordinates just like it did for win/dlgs but SETSIZE is expecting to have "clientwindow" coordinates for controls instead of screen coordinates like win/dlgs.  e.g. SETSIZE expects the same sort of coordinates that were used to create the control.

The work around for coordinates that aren't known up front (as is the case with my annunciator and grouppushbutton custom controls since I don't where the programmer will place the controls on the screen but I have to find them in order to increase their w and h based upon the programmer's configuration) is pretty straight forward.

For a control used GETSIZE to retrieve l,t,w,h
Then use

Code Select Expand

DECLARE IMPORT, _ScreenToClient ALIAS ScreenToClient(hwnd AS INT,lpPoint AS POINT),INT
to convert the coordinates.
I'm doing it with the following little block of code:

Code Select Expand

sub ConfigPBGroupLM(win as WINDOW,d as int,num as int,w as INT,h as int, id as UINT )
'd - direction 0=horiz 1=vert
'num - number of buttons
'w - width of 1 button
'h - height of 1 button
int l,t,w1,h1
uint hhnd
winrect rc
point p
'used winrect variable because it was convienent
GETSIZE win, rc.left, rc.top, rc.right, rc.bottom,id

p.x=rc.left:p.y=rc.top
_ScreenToClient(d1.hwnd,p)
select d
case 0 :'horz
w1=w*num+8
h1=h+8
case 1 :'vert
w1=w+8
h1=h*num+8
endselect
SETSIZE win, p.x,p.y, w1, h1,id

Hope I didn't make this too convoluted and drawnout to understand and that it helps someone in the future because it is somewhat obscure.

There might be a chance in a future revision that Paul would change to GETSET function to make the adjustment for controls automatically.

Larry
   

[Ionic Wind Support Team]

Larry,
There are two windows API functions that take care of the conversions for you.

ScreenToClient and ClientToScreen

Which take a POINT and a handle to a window and convert that point back and forth between client and screen coordinates.  Simple and easy to use, no "Gotchas" at all.

You just needed to ask    Or search MSDN that is.

Paul.

[Ionic Wind Support Team]

OK I see you already figured that out .  I did mention in the users guide that the coordinates returned are reletive to the screen.  GETSIZE just calls GetWindowRect in a convenient way, so you don't need to use a RECT structure. 

[LarryMc]

Paul

I don't really want to play "mental pingpong" but:

I did mention in the users guide that the coordinates returned are reletive to the screen.

That's true for GETSIZE but nothing is mentioned about SETSIZE.  So my assumption was that SETSIZE was just like GETSIZE; which it is for windows and dialogs but not for controls.

...so you don't need to use a RECT structure

Knew that as I mentioned in a comment in my code snippet:

'used winrect variable because it was convienent

There are two windows API functions that take care of the conversions for you....
...You just needed to ask    Or search MSDN that is.

After the fact that is easy to say; especially for someone who is an expert with the API.  But that isn't one's inital thoughts when first using GETSIZE/SETSIZE on a control after having used them numerous times with windows and dialogs.

My whole point was that if you aren't an expert with API and are simply an EBasic programmer trying to read the help file and use the commands then you MIGHT run into the same "gottcha" I ran into.

It took me a lot longer to figure out what was really happening then it took me find the solution. Once I figured out conversion to "dialog units" had nothing to do with my problem everything sort of fell into place.

Had it not been for the EBasic source code and MSDN I wouldn't have been able to figure out what was indeed a "simple fix" on my own.

I was just trying to keep someone else from wasting the same amount of time that I did and provide a little "tutorial", although somewhat crude.

Not intended as a criticism of you or EBasic in any way.

Larry

[Ionic Wind Support Team]

Larry,
If you ask the right questions you're more likely to get the right answers.     I mentioned the difference between dialog units and pixels because your question didn't mention you were having problems understanding GETSIZE and SETSIZE.

When I calculate the desired width and height along with the original left and top I put those numbers in a RESIZE statement.

The result is that the control kind of moves to an aribtrary location.  And if I change the dialog size and rerun the program my control moves.
As the dialog gets wider my control moves to the left and vice versa.

I noticed that the controlex function does some calculations and puts the l,t,w,h in a IBDLGTEMPLATE structure but the
SETSIZE fuction doesn't use that structure.

Based on what you posted I asked you to show some code.  As I wasn't sure how you were handling it.

Perhaps an error of ommission on my part, but the reason I mention that GETSIZE returns coordinates relative to the screen is that every other command takes the parent window into account.  I'll make a note of it in the users guide. 

Paul.

[LarryMc]

You know how easy I get confused and most of the time I don't know what an intelligent question would be.

A note in the help would suffice for that "other" idiot like me. (there has to be at least one, doesn't there?)

thanks for your patience

Larry

[Jerry Muelver]

A note in the help would suffice for that "other" idiot like me. (there has to be at least one, doesn't there?)

That would be me! (waves hand in the air) 

I just came back from a fruitless trip through the docs looking for an explanation of a "default button" on a dialog. Nothing, yet.There are a lot of details out there that authors hope their readers already know....

[LarryMc]

Search for @CTLBTNDEFAULT

Larry

[Jerry Muelver]

I was just getting close to that! 

[hugh]

I have tried this with my bingo program, ie control 101 is that which displays the random number called. text size set to 1000.

Code Select Expand

setsize w1,0,0,400,600,101 :'                              just  a test to make random number larger then set it to fit screen
    setfont w1,"Ariel",3000,101
   SETCONTROLCOLOR(w1,101,RGB(255,255,0),RGB(255,0,0))

Code Select Expand

tried different combinations, works fine for me on vista home premuim.
but the text size stays the same?.
anyone got any ideas; or do i have to use a special command to enlarge the text to fit the enlarged control.

regards.

Hugh

[Ionic Wind Support Team]

You're missing a couple of parameters in your SetFont statement.

See the users guide:

SETFONT(win as WINDOW,typeface as STRING,height as INT,weight as INT,OPT flags=0 as UINT,OPT id=0 as UINT)

You have to specify the height (in points), the weight, the flags and the ID.  For a font that is 1 inch high on a control id of 101 it would be:

setfont w1,"Ariel",72,400,0,101

The height is specified in points, 1 point = 1/72nd of an inch.

The weights is the thickness of the lines used to draw the font. 400=normal, 800=bold with various degrees of thickness in between.

Paul.

[Earn]

If you ask the right questions you're more likely to get the right answers.   

I typically find that once I know enough to ask the right question I have the answer. 

[aurelCB]

Quote from:Paul Turley on February 23.2008.11.18.55 AM
Hey man today is July,and your reply has no conection with topic theme.

[LarryMc]

Quote from:Paul Turley on February 23.2008.11.18.55 AM
Hey man today is July,and your reply has no conection with topic theme.

And your point is?

Larry

[aurelCB]

I just reply to Earn,nothing else...

[Earn]

Just a little levity.  Sorry if it bothered you.