Over at the LB Community Forum, Rod has proposed that the REFRESH command should be modified to have the side-effect of updating the WindowWidth and WindowHeight variables to correspond to the window's Client Area (i.e. excluding the title bar and borders). The argument is that manually resizing the window has this effect anyway, and it would be useful to be able to force the update in code.

It would be easy enough to make this change in LBB (albeit that it would slow down REFRESH slightly) but I'm a little uneasy about Rod's claim that "It won't break anything". Although the LB docs suggest that REFRESH is only useful in a RESIZEHANDLER (in which case WindowWidth and WindowHeight will already have been changed) it's not impossible that some existing programs use it at different times and might be broken by these variables changing 'unexpectedly'.

What are people's feelings on the pros and cons of this proposed change? Of course if Carl is persuaded to change LB 4 that settles it, but if I lead the way with LBB I don't want to introduce an undesirable incompatibility.

I don't use the Refresh statement in my program so changing how it works wouldn't matter to me.

But, I have always thought it was strange that it changes the values to the size of the client area instead of giving the new window sizes. If you are going to go your own direction with this perhaps you could introduce two new variables, ClientWidth and ClientHeight? That might be less confusing to users.

perhaps you could introduce two new variables, ClientWidth and ClientHeight? That might be less confusing to users.

But what about WindowWidth and WindowHeight? Many existing Liberty BASIC programs rely on their current behavior and any change would have unacceptable compatibility implications. On that basis I think the introduction of ClientWidth and ClientHeight variables could actually add to the confusion.

What Liberty BASIC should have done, from the start, is use WindowWidth and WindowHeight consistently to refer to the client size. Normally the programmer isn't interested in the overall window dimensions: by definition the non-client areas (title bar and borders) aren't the responsibility of the programmer, so why should he care how large they are?

So if you argue that LBB should try to 'set things right' my solution would be not to introduce new variables but, under control of some directive, optionally make WindowWidth and WindowHeight control the client area when a window is opened. That's straightforward because there's an API (AdjustWindowRect) which calculates the window size that results in a given client size.

I don't plan to do that, because I no longer have ambitions of moving LBB in that direction, but it's what I would want to do if I had!

Not sure what the answer is. "resize.bas" that ships with LB doesn't work properly so it would seem Carl struggled with how it should work. An LBB directive that can change how it works might be the best way to go.

It works "properly" after the window is manually resized, doesn't it? It's only the initial state that is wrong, and that's precisely Rod's point: if there was some easy way of getting the client dimensions into WindowWidth and WindowHeight without having to manually resize the window it would fix that issue. Here it's done using an API call to prove the point:

I can only assume that he wasn't/isn't familiar with the AdjustWindowRect API, the use of which would have made it very easy for WindowWidth and WindowHeight to refer always to the client area, solving this and other problems.

As Raymond Chen frequently says in his Microsoft blog, a time machine would be very helpful!