Controlling width of visible child window (Quickwin)

[dboggs]

I'm having trouble controlling the width of the visible window, in terms of characters, in Quickwin. Say I want a window 40 text characters wide by 20 text rows high. If I create the window using SETWINDOWCONFIG(wc), all is fine. But now I want the visible window to be only 10 rows high, with a scrollbar to access all 20 rows. So I set this property of the visible window using SETWSIZEQQ(unitno, winfo). Presto this creates a vertical scrollbar, BUT the window isn't widened to accommodate this; instead the scrollbar lies inside the original window, covering up about two columns of text, so now the *effective* window width is 38 characters instead of 40! Further, btw, the system recognizes that the full width cannot be displayed, and so conveniently gives me also a horizontal scrollbar to see the two remaining columns! I think this is bizarre!

If I try specifying a width of 42 characters SETWSIZEQQ, the system thinks that I am asking for an oversize visible window, shrinks the visible window width to match the virtual width, seemingly ignorant of the fact that extra width will be needed for the vertical scrollbar.

So it seems impossible to get a visible window showing exactly X characters wide, if the height of the window is less than the height of the virtual window.

I can awkwardly get around this by specifying a virtual window42 characters wide x 20 rows high using SETWINDOWCONFIG, then set the visible window to 42 characters x 10 rows using SETWSIZEQQ. This will give me a window displaying 40 characters wide, but there will still be a horizontal scrollbar to access columns 41 and 42 which I really don't want to see at all.

Can anybody help me with this, or at least confirm that my observations are correct?

[Paul_Curtis]

Retrieve the child window's handle, then

[bash]rval = SetWindowPos (child_handle, NULL, x, y, width, height, SWP_SHOWWINDOW)[/bash]

where x,y are the pixel locations of the ULC, and width, height are the window extents.

Of course if you chose to use the windows API instead of Quickwin you would have defined the text font, for which you could then obtain metrics such as the avg. char width, and thus set your visible client area exactly to accommodate some number of characters. As is, you'll have to make some empirical guesses.

[dboggs]

Thanks Paul. I will try your suggestion, but I have to brush up on the API calls in Quickwin before doing so.

I must say, however, that I had really hoped for confirmation from someone skilled in Quickwin that either (a) there is some simple quickwin procedure I have overlooked, or (b) my interpretation is correct and the goal is indeed impossible.

At first glance, it appears that your suggestion is merely an alternative way to define the window size using AP, and that it won't take care of the excess scrolling height that I need (without some additional API stuff). Also, from your comments about defining the text font I have to wonder if you are really familiar with Quickwin. In my case I know that the character width is exactly 8 pixels because I simply accepted the Quickwin default. There is no need for empirical guesses or explicit font metric retrieval unless I want something special, and this would be very easy in Quickwin.

[dboggs]

OK, I have run the API call as suggested by Paul. As I feared, this is just an alternate way of sizing the window, and the results are the same.

I suppose that there are other API calls that can be used to achieve the desired result--i.e., a vertical scrollbar only when required, and a horizontal scrollbar only when required, as opposed to the Quickwin solution of adding both scrollbars when either one is required.

Can anyone help me with this?

[Paul_Curtis]

Scrollbars are automatically added when your content drawn into the window's client area becomes larger than the client area; this is a Windows feature which has nothing to do with Quickwin, although Quickwin evidently includes scrollbars as its default window style. If you do not want to see scrollbars, then you must either enlarge the window's client area or decrease the size of your content. If you know the window's handle, you can change the style with
SetWindowLong(handle, GW_STYLE, new_style), where new_style omits the scrollbar flags.

Or, alternatively, you could lose the Quickwin and create the window in your own code, in which case all of the window's attributes would be under your explicit control, and you could easily specify "no scroll bars" by omitting scroll-bar flags from the DW_STYLE argument.

You have chosen to use an abstraction layer which deliberately hides most window construction details, and now encounter a situation which requires more atomic control than the abstraction layer provides. It seems a bit circular to then complain that the API-level tools which would solve your problem are incompatible with the abstraction layer.