Loading ...
Sorry, an error occurred while loading the content.

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

Expand Messages
  • 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
    Message 1 of 8 , Jul 17, 2013
      On 17/07/2013 11:38, Andre Sihera wrote:
      > 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?

      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.

      >> 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 ...
      >>>> 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:
      >>>>>> On 11/07/2013 10:34, Charles wrote:
      >>>>>>> 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).
      >>>>>> 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
      >>> Mike
      >> Mike

      There you go thinking again!

      You received this message from the "vim_dev" maillist.
      Do not top-post! Type your reply below the text you are replying to.
      For more information, visit http://www.vim.org/maillist.php

      You received this message because you are subscribed to the Google Groups "vim_dev" group.
      To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscribe@....
      For more options, visit https://groups.google.com/groups/opt_out.
    Your message has been successfully submitted and would be delivered to recipients shortly.