GETWSIZEQQ does not always return the correct window size

[dboggs]

In my Quickwin projects I usually create a child window using SETSIZEQQ, often followed by SETWINDOWCONFIG so that the visible and virtual window sizes are the same, and there are no scroll bars. In another part of the program (or even in a totally separate library routine), which is too separated to conveniently pass the window width and height, I need to inquire the window size. The natural way to do this is with GETWSIZEQQ. Unfortunately, this only returns the right width when the virtual window is larger and the visible window has scroll bars. If there are no scroll bars, the width returned is 2 or 3 columns smaller--it's as though GETWSIZEQQ always assumes there is a vertical scroll bar whether it's actually there or not.

The following program demonstrates this:

! Demonstration of opening, sizing, locating a child window in Quickwin

[fortran]PROGRAM WindowDemo

USE IFQWIN

IMPLICIT NONE

TYPE (QWINFO) :: winfo

TYPE (WINDOWCONFIG) :: wc

INTEGER(4) :: i4

LOGICAL(4) :: l4

CHARACTER(50) :: ruler

ruler = '----+----1----+----2----+----3----+----4----+----5'

! Initialize window and set unit number..

OPEN (1, FILE='USER')

! Open a 40w x 20h visible window.

winfo.X = 0 ! Starting column within project frame

winfo.Y = 0 ! Starting row within project frame

winfo.W = 50 ! Window width in characters

winfo.H = 20 ! Window height in text rows

winfo.TYPE = QWIN$SET

i4 = SETWSIZEQQ (1, winfo)

! Can the correct width be inquired?

i4 = GETWSIZEQQ (1, QWIN$SIZECURR, winfo)

WRITE (1, *) 'Width reported by GETWSIZEQQ =', winfo.W ! Reports 50 - OK

WRITE (1, '(A)') ruler(1:winfo.W)

READ (1, *)

! Set width of virtual window same to eliminate scroll bars.

! (Note: this erases any text in the window.)

wc.NUMTEXTCOLS = 50

wc.NUMTEXTROWS = 20

l4 = SETWINDOWCONFIG (wc)

IF (.NOT.l4) l4 = SETWINDOWCONFIG (wc)

!!WRITE (1, '(A)') ruler(1:wc.NUMTEXTCOLS)

WRITE (1, *) 'Scroll bars are now gone'

! Can the correct width be inquired?

i4 = GETWSIZEQQ (1, QWIN$SIZECURR, winfo)

WRITE (1, *) 'Width reported by GETWSIZEQQ =', winfo.W !

WRITE (1, '(A)') ruler(1:winfo.W)

READ (1, *)

l4 = GETWINDOWCONFIG (wc)

WRITE (1, *) 'Width reported by GETWINDOWCONFIG =', wc.NUMTEXTCOLS !

WRITE (1, '(A)') ruler(1:wc.NUMTEXTCOLS)

READ (1, *)

WRITE (1, *) 'Note GETWSIZEQQ should not be used to get window size'

END PROGRAM WindowDemo[/fortran]

There may be a similar problem with the window height (I haven't investigated). GETWINDOWCONFIG can be used to inquire the window width as in the example above, but in general that is not useful because it returns the virtual window size, which may be different from the visible window size, and there is apparently no way to determine this. This turns out to be quite problematic. In fact, GWSIZEQQ seems to be pretty useless. Can it be fixed?

[andrew_4619]

Actually I had this problem recently, it is not a bug! If you read the help there is a key word that easily escapes the attention! GETWSIZEQQ returns the information on the CLIENT area of the window this area does not include the header, borders and scroll bars, only the rectangle area that is 'user writable'.

I used the API functions below to get what I needed,  

GetWindowRect &

ScreenToClient

EDIT - in your case:

[fortran]use ifwin​

integer(bool)                :: bret

type(t_rect)                 :: rcClient

integer(handle)            :: hWnd   ! handle to window

integer(2)                    ::  width, height

bret=GetWindowRect(hWnd, rcClient) ! whole window area, this is in screen coords

width = rcClient%right-rcClient%left

height=rcClient%bottom-rcClient%top

[/fortran]

[andrew_4619]

.... I should add the name of the routine is a bit misleading, GETPORKQQ returns the amount of beef! A handful of extra words in the help would be helpful in this instance.

[dboggs]

I know that GETWSIZEQQ returns the "client area," which does not include the borders and scroll bars. But the point is (which is demonstrated by my program), if there are no scroll bars, the width returned is too small. In this case the client width goes from border to border, but the width returned by GETWSIZEQQ seems to make an allowance for a vertical scroll bar, even when it is not there. This is not useful, if you are trying to size and locate things very accurately inside the borders. As a user I can write to that space (which the demo program does) so I still think it is a bug.

I will experiment with GetWindowRect--thanks for that suggestion. But it's frustrating if the Quickwin routine was designed to do this and it doesn't.

[andrew_4619]

there is also::

 bret=GetClientRect(hWnd, rcClient)​

[jimdempseyatthecove]

I agree with dboggs. When scroll bars are not present, GETSIZEQQ should not reduce the size by the size of the missing scroll bar. Same for the possibly missing title bar, status, etc... Consider what may happen when you are in full screen mode.

Jim Dempsey

[andrew_4619]

not totally sure on that Jim, I guess this way it is guaranteed that content is not obscured should the scroll bar appear. You can work around it if you know what the width of the scroll bar would be and if it is there or not. I was not aware of this 'feature' and would at least suggest the help should give some additional info. This type of problem wastes a lot of time ad dboggs has probably found.   

My problems was different in that I wanted to capture either the client area or the whole window as a bitmap file depending on my whim. The Win API was the only way (GetWindowRect, GetClientRect & ScreenToClient).

[dboggs]

"...should the scroll bar appear"?! Yikes! Are you suggesting that the two or three rightmost columns should never be used? The scroll bar doesn't appear and disappear at the system's whim. There are Quickwin tools to control this. GETSIZEQQ is not consistent with them.

[andrew_4619]

If you resize so that the content does not fit any more the scroll bar(s) appear and visa versa is what I was thinking about. I am not disagreeing with you BTW something needs to change either the function or the help or both.

I suspect the former will meet with resistance as code that is currently OK might not be OK if you change the GETWSIZEQQ output. For new code and if you are aware of this issue you can work around by leaving some extra space or by making your own function using the winapi. It will only be a handful of lines of code like my example above.

[dboggs]

How about it, INTEL, do you have a position on this issue?

[Steven_L_Intel1]

I agree that this seems somewhat inconsistent, but given the LONG history of this code, I am disinclined to suggest it be changed as, as app4619 suggests, this could break existing programs. I note that the user can manually resize the window, causing scroll bars to appear, and disappear, and the program won't know this unless it asks again. (If there is a callback functionality for a notice, I'm not familiar with it.) I noticed that when playing with the program, very small changes to the window size made the vertical scrollbar appear and disappear.

My advice is to set the window size to what you need.

[dboggs]

OK Steve, thanks for checking into this.

This decision means that, for those projects involving various windows that might be scattered throughout various proceedures in a large code, and manipulations are required in the windows to arrange various display blocks, the visible window size (as originally set by winfo.h and winfo.w) must be transported throughout the code--using arguments, common, modules, etc. since they cannot be reliably inquired. Or, forget the quickwin GETWSIZEQQ and resort to API as suggested above.

I understand why Intel may not want to fix this. But, I think it would be appropriate to fix the documentation so that users no longer expend oodles of time using reverse engineering to expose/confirm the flaw and look for alternatives.

[andrew_4619]

Could you just create a routine called myGETWSIZEQQ  with the same call interface perhaps, do a global replace and then just write myGETWSIZEQQ using (GETWSIZEQQ+ a fudge)  or (using win api) ? 

[dboggs]

Yes, I think I will create a library routine "myGETWSIZEQQ" as you suggest (maybe "GETWSIZEQQfixed"?), and that routine will use API to return the correct sizes.

But I still think Intel should correct the documentation. All of this child window stuff is confusing enough without incorrect or misleading instructions lying around.