Gap between scrollbar and window border when compiled with Visual Studio 2012

[Charles]

Hi,

Does anyone know why when compiled with visual studio 2012, the vim
gui has gap between the scrollbars and the window borders.

Here's the screenshot of vim compiled with visual studio 2010

http://imgur.com/lI05rgq

And here is when compiled with visual studio 2012

http://imgur.com/iLeVis1

Both are compiled with the same source code, same configuration, same
platform (x64).

[Mike Williams]

Definitely something strange going on with VS2012 builds. Starting with
gvim -u NONE -U NONE gives a 79x24 window instead of 80x25. Doing :set
columns=80 results in no change in columns but the number of lines
increases by one, but the window size doesn't change so you can no
longer see the command line. The only way to see the command line is to
use the mouse to resize the window.

Will take bit longer to spelunk my way to the relevant code. Anyone got
any pointers to help speed up the investigation? Or can someone look at
the code and have a d'oh moment?

Mike
--
Don't learn the tricks of the trade - learn the trade.

[Andre Sihera]

Hi,

I haven't taken a look at the VIM code, but a logical place to start
looking might be
for any window size or decoration calculation code that calls the
GetSystemMetrics()
function with any of:

- SM_CXBORDER
- SM_CYBORDER
- SM_CXEDGE
- SM_CYEDGE
- SM_CXVSCROLL
- SM_CYHSCROLL

With each new version of Visual Studio, the default version number of
the Platform
SDK (a.k.a Windows SDK) which is set via the variables WINVER and
_WIN32_WINNT
is increased to reflect the newest UI rendering rules. This means that
if you haven't
been ultra-strict in your calculations of window sizes and system
controls the UIs will
look broken on all versions of Windows released prior to version of VS
that is being
used.

Cheers,

Andre.

[Andre Sihera]

Actually, come to think of it, the best logical place to start looking would be at
any window size or decoration calculations that *don't* use GetSystemMetrics().

Cheers,

Andre.

Hi,

I haven't taken a look at the VIM code, but a logical place to start looking might be
for any window size or decoration calculation code that calls the GetSystemMetrics()
function with any of:

- SM_CXBORDER
- SM_CYBORDER
- SM_CXEDGE
- SM_CYEDGE
- SM_CXVSCROLL
- SM_CYHSCROLL

With each new version of Visual Studio, the default version number of the Platform
SDK (a.k.a Windows SDK) which is set via the variables WINVER and _WIN32_WINNT
is increased to reflect the newest UI rendering rules. This means that if you haven't
been ultra-strict in your calculations of window sizes and system controls the UIs will
look broken on all versions of Windows released prior to version of VS that is being
used.

Cheers,

Andre.



On 15/07/13 22:59, Mike Williams wrote:

[Mike Williams]

On 15/07/2013 22:19, Andre Sihera wrote:
>
> Actually, come to think of it, the best logical place to start looking
> would be at
> any window size or decoration calculations that *don't* use
> GetSystemMetrics().
>
> Cheers,

Thanks for all the pointers I have received. I hope to be able to start
looking at it later on today.

Mike
--
Men look before using a toilet. Women find this illogical.

[Mike Williams]

On 16/07/2013 09:28, Mike Williams wrote:
> On 15/07/2013 22:19, Andre Sihera wrote:
>>
>> Actually, come to think of it, the best logical place to start looking
>> would be at
>> any window size or decoration calculations that *don't* use
>> GetSystemMetrics().
>>
>> Cheers,
>
> Thanks for all the pointers I have received. I hope to be able to start
> looking at it later on today.

Hacking around with the system metrics I can solve the problem. However
it does raise a new one - it requires a build with WINVER set to 0x0600.
The down side is that executables wont then run on XP or earlier
versions of Windows.

An alternative approach is to build VIM with the v110_xp toolset. This
should cause the existing code to get the same metrics as it does with
VS2010. The thing to note is that by default VS2012 builds don't work
on XP, and certainly wont on Win2k which VIM has supported to date.

Something is gonna have to give or there a going to be problems with
users not knowing which platforms their downloaded Windows executable
will run. Should we cast Win2K support adrift, possibly kept as a
optional build for those that know what they are doing? Should we not
support VS2012 builds at all (you can still get VS2010 Express downloads
but no idea for how much longer with 2013 on the horizon)? Should VIM
report the Windows compiler used to help with support calls along the
lines of "VIM wont start on Windows"? Should VIM move to multiple
builds for Windows for the older versions?

Lights blue touch paper, retires to normal day work ...

Mike
--
There you go thinking again!

[Andre Sihera]

On 17/07/13 18:32, Mike Williams wrote:
> On 16/07/2013 09:28, Mike Williams wrote:
>> On 15/07/2013 22:19, Andre Sihera wrote:
>>>
>>> Actually, come to think of it, the best logical place to start looking
>>> would be at
>>> any window size or decoration calculations that *don't* use
>>> GetSystemMetrics().
>>>
>>> Cheers,
>>
>> Thanks for all the pointers I have received. I hope to be able to start
>> looking at it later on today.
>
> Hacking around with the system metrics I can solve the problem.
> However it does raise a new one - it requires a build with WINVER set
> to 0x0600. The down side is that executables wont then run on XP or
> earlier versions of Windows.

Why does it require WINVER to be set to 0x0600 or later?
GetSystemMetrics() has
been in GDI since Windows 3.0 over 20 years ago and key metrics like window
borders and scrollbar widths haven't changed their meaning throughout
that entire
time.

You should at least be able to set WINVER to somewhere around 0x0400 (NT
3.51/
Windows ME).

Which parameters are you specifying?

[Mike Williams]

There is a new parameter to be used, SM_CXPADDEDBORDER, that is only
defined when WINVER is 0x0600. I guess we could hard code the value
(92) in so as to not require the WINVER to be set in the build.
GetSystemMetrics() should return 0 for older platforms. Seems a hacky
approach, but not without precedent in VIM.

This is all separate to the issue of VS2012 builds not working on 2K/XP.