large controls and SetWindowPos


I want to use same comtrols (Drawgrids) of very large size, more than 32k pixels high.

It is possible to assign (for instance)

var agrid:Tdrawgrid;

// in Formcreate of the mainform
 // create of agrid etc.


This will displayed correctly.

If you change the size of such large grid if the form is visible, say


than agrid.height is implicit also changed an set to 32767.

I determine, that this happens while the program calls SetWindowPos.

(SetWindowPos is the API-function from user32.dll.)

Nevertheless setwindowpos has integer - parameters (32-bit integer), it cuts the values to the maximum of 32767?

Is there any possibility to avoid this?

Any hint will be welcome!


p.s. I use win2000 SP4 and Delphi 6 (U2), but its the same under win2000 SP3.

Who is Participating?
hello  nmm, I'm not sure where you get your values from for integer max value, according to several sources (the folowing is from Delphi Help)

Integer    –2147483648..2147483647           signed 32-bit

and in the WM_SIZE message it is limited to a Word value. . .

Word     0..65535      unsigned 16-bit

so in the   SetWindowPos( ) function you can go up to  2147483647 for the height

however your line


seems like a unusable size for a window, I would think that you should be able to use some window height that is smaller than the Screen Height, especially since the Draw grid can have scroll bars. . . are you certian that you must have a  48000 window height?
Hello.  When a window is resized, it sends a WM_SIZE message.  Unfortunately the width and height parameters are set using only 16bit integers.  So you are limited to a size of 32K.  From MSDN Site: (


If the SetScrollPos or MoveWindow function is called for a child window as a result of the WM_SIZE message, the bRedraw parameter should be nonzero to cause the window to be repainted.
Although the width and height of a window are 32-bit values, the nWidth and nHeight parameters of the WM_SIZE message contain only the low-order 16 bits.

nmmAuthor Commented:
Hi Tyrsis,

I will try to handle wm_size myself, may be this will work...
unfortunately the URL dosen't work, eaven

dont work, netherthless this adress is displayed by microsoft, if one search MSDN.


ps to Slick812: yes I really need that unusual window size.
Cloud Class® Course: CompTIA Cloud+

The CompTIA Cloud+ Basic training course will teach you about cloud concepts and models, data storage, networking, and network infrastructure.

???, I'm not sure what your last comment is about at all? ?
I guess you want information about what is on the MSDN web page?

here is what it says - - - - - ->

WM_SIZE Notification

The WM_SIZE message is sent to a window after its size has changed.

A window receives this message through its WindowProc function.



    WPARAM  wParam
    LPARAM  lParam;


wParam - Specifies the type of resizing requested. This parameter can be one of the following values.

    SIZE_MAXHIDE - Message is sent to all pop-up windows when some other window is maximized.
    SIZE_MAXIMIZED - The window has been maximized.
    SIZE_MAXSHOW -  Message is sent to all pop-up windows when some other window has been restored to its former size.
    SIZE_MINIMIZED - The window has been minimized.
    SIZE_RESTORED - The window has been resized, but neither the SIZE_MINIMIZED nor SIZE_MAXIMIZED value applies.

lParam - The low-order word of lParam specifies the new width of the client area.

    The high-order word of lParam specifies the new height of the client area.

Return Value  - If an application processes this message, it should return zero.


If the SetScrollPos or MoveWindow function is called for a child window as a result of the WM_SIZE message,
 the bRedraw or bRepaint parameter should be nonzero to cause the window to be repainted.

Although the width and height of a window are 32-bit values, the lParam parameter contains only the low-order 16 bits of each.

Notification Requirements  -
  Minimum DLL Version None
  Header Declared in Winuser.h, include Windows.h
  Minimum operating systems Windows 95, Windows NT 3.1
I do not think that the system accually uses this  WM_SIZE message, this is Sent  AFTER the window has be sized, to  tell a coder that the window has ben resized so you can do code to move or resize child windows. . . I do not think that you will need to handle this message,  just let it pass to system (the usual default)

you might just reset the grid height  AFTER you set the grid width -


But I would be in search of a way to use normal window heights (I.E  less than screen height)
nmmAuthor Commented:
Hi Slick812,
thanks you for your comments. I try something and now it seems, that the large height is
cut by the Api-function  GetWindowRec.

Handle of wm_size will not do, I cheked it.

I tryed something like

var  saveheight:ingeger;

but it doesn't work.

If you assign that large values *before* the window is visible, than it becomes so large I want, and the visible window
than is really 48000 heigh: I had a look at the windows height from "extern" using windowse.exe
(, and it shows 48000!

GetWindowRect is called by every assignment
height:=something  or width:=something
and GetWindowRect returns the rect-coordinates in a 16-integer-manner.

I try under WinXP Porf. SP1: the same "cut off" happens.

By calling SetWindowPos several WM_ messages are send (and can be handled from the calling programm.
But if you call GetWindowRect no message will posted.
I'am afraid, that one can overcome this only, if one changes the borland-Code of controls.pas
(eliminate all calls of GetWindowRect.).


I do not have time now to search through the delphi source code for a limiting factor for your size, I think you may be correct to say that in the source code that there may be some delphi code that will cut off the height of your window, probally with a good reason . .


I do not know where you get your infomation from, but the  GetWindowRect(  )  function is NOT linited to  "16-integer-manner" it gets a C-Code  RECT structure (a delphi TRect) which has four 32-bit Integers in it. . . There must be a way to not use such gigantic window sizes, the purpose of a "Window" is for Graphacal optical display to the user (so he can see something), and the user CAN NOT SEE anything larger than the Monitor screen, so any thing larger than screen size would seem to be a bad idea, since if you can not see it why have it?

But if you are determined to get around the delphi Height restriction, then stop using the object "Width" and "Height"

do NOT use


use the API functions instead

MoveWindow(agrid.Handle, 44, 157, 357, 48000,True);

or maybe SetWindowPos mat do better

SetWindowPos(agrid.Handle,0, 0, 0, 357, 48000,
                  SWP_NOMOVE or SWP_NOZORDER);

but remember, the Width and height will NO LONGER  have the correct width and height in them if you need to know the true width and height you will call the GetWindowRect function

aRect: TRect;

GetWindowRect(agrid.Handle, aRect);
I'm pretty certain as I said above that when a window (any window that isn't virtual and is visible) gets sent a WM_SIZE message to size it.  Those API functions you're calling are just doing a SendMessage(hWnd, WM_SIZE, ...) to the window in order to size it.  

But anyhow, I think what Slick is trying to say is that, by definition, you really shouldn't be creating a control that is so large.  You should only be creating controls that are at most the size of the screen.

If you trace back through the Delphi code you can probably find out why it's limiting your height and width, and it will be next to impossible to fix without creating a window from scratch.  You can try sizing with the win32 api functions listed above, but I have my doubts.  Though hopefully it works for you.

just tell us why your drawgrid has to be so big
and maybe we find a way to solve the problem so that the window stays below 32k in height
nmmAuthor Commented:
although none of the above comments give an satisfactory answer, I decide to split the points, because it seems, that Windows isnt able to hable such large controls right. It actually can handle it, bat there are inconsistecies, that are not due to Delphi but Windows-code itself. So there might be up to now no way to use large controls...
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.