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

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

Expand Messages
  • 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
    Message 1 of 8 , Jul 11, 2013
    • 0 Attachment
      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).

      --
      --
      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.
    • 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
      Message 2 of 8 , Jul 15, 2013
      • 0 Attachment
        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
        --
        Don't learn the tricks of the trade - learn the trade.

        --
        --
        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.
      • 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
        Message 3 of 8 , Jul 15, 2013
        • 0 Attachment
          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

          --
          --
          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.
        • 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
          Message 4 of 8 , Jul 15, 2013
          • 0 Attachment

            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:
            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

            --
            --
            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.
             
             
          • Mike Williams
            ... 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
            Message 5 of 8 , Jul 16, 2013
            • 0 Attachment
              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.

              > 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
              --
              Men look before using a toilet. Women find this illogical.

              --
              --
              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.
            • Mike Williams
              ... 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
              Message 6 of 8 , Jul 17, 2013
              • 0 Attachment
                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 ...

                >> 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.
              • Andre Sihera
                ... 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
                Message 7 of 8 , Jul 17, 2013
                • 0 Attachment
                  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?


                  >
                  > 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

                  --
                  --
                  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.
                • 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 8 of 8 , Jul 17, 2013
                  • 0 Attachment
                    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
                    >


                    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.