Home Dashboard Directory Help
Search

Regression: ::GetSystemMetrics delivers different values by Peter Schregle


Status: 

Closed
 as External Help for as External


9
0
Sign in
to vote
Type: Bug
ID: 753224
Opened: 7/11/2012 4:06:00 AM
Access Restriction: Public
0
Workaround(s)
view
3
User(s) can reproduce this bug

Description

Take the following lines of code:


        int cx = ::GetSystemMetrics(SM_CXSIZEFRAME);
        int cy = ::GetSystemMetrics(SM_CYSIZEFRAME);
        int cp = ::GetSystemMetrics(SM_CYCAPTION);

When compiled with Visual Studio 2010, on my Windows7 machine this yields: cx == 9, cy == 9 and cp == 27.

If I compile the very same code with Vision Studio 2012 RC on the same machine, this yields: cx == 5, cy == 5 and cp == 27.

Visually checking, the values returned for Visual Studio 2010 are correct, the values returned for Visual Studio 2012 are not correct.

Details
Sign in to post a comment.
Posted by Microsoft on 11/7/2012 at 10:15 PM
Hi Bill,

as a workaround you can compile your application for pre-vista:
add the following property to your project file:
<subsystemversion>5.01</subsystemversion>
http://msdn.microsoft.com/en-us/library/hh965708.aspx

Thank you,
The Windows Forms Product Team
Posted by Bill Henning [Actipro] on 11/6/2012 at 12:08 PM
Is there a fix or workaround for this issue? We are encountering this same issue in our C# app where based on which VS version we use, we get a different result and it causes problems with our custom window chrome in WPF.
Posted by Microsoft on 7/17/2012 at 10:25 AM
Mike - you got it. This is due to the linker's minimum version being different in VS 2010 vs. VS 2012. The AppCompat shim is based on the minimum supported OS defined by the linker rather than the _WIN_32_WINNT value used at app compile time.

Thanks!
Alex Thaman
Senior Test Lead
Visual C++ Team
Posted by Mike Danes on 7/16/2012 at 11:32 AM
This is likely caused by VC2012 setting OS/image/subsystem version in the PE header to 6.0 unlike VC2010 which used 5.01/0.0/5.01.
Posted by Peter Schregle on 7/14/2012 at 8:07 AM
In both cases I'm running the code on Windows 7.
Posted by Microsoft on 7/13/2012 at 1:01 PM
"Take the following lines of code: int cx = ::GetSystemMetrics(SM_CXSIZEFRAME); int cy = ::GetSystemMetrics(SM_CYSIZEFRAME); int cp = ::GetSystemMetrics(SM_CYCAPTION); When compiled with Visual Studio 2010, on my Windows7 machine this yields: cx == 9, cy == 9 and cp == 27. If I compile the very same code with Vision Studio 2012 RC on the same machine, this yields: cx == 5, cy == 5 and cp == 27. Visually checking, the values returned for Visual Studio 2010 are correct, the values returned for Visual Studio 2012 are not correct."

Peter, when you compile the code using Visual Studio 2012 RC, are you running the resulting compiled program on Win7 or Win8?
Posted by Peter Schregle on 7/12/2012 at 10:08 PM
Please explain, why this is a Windows issue.
Posted by Microsoft on 7/12/2012 at 11:03 AM
Thank you for your bug submission. The issue you reported appears to be a Windows issue, and we have forwarded the bug to them. We will close the bug in Connect, as they have now received it in their internal database, and they will evaluate it for the product. If this issue is severe, causing critical business situations or blocking your product development or deployment, please go to http://support.microsoft.com or call 1-800-MICROSOFT for assistance. For Microsoft premier customers, please contact your administrator, your Technical Account Manager, or your Microsoft premier account representative.
Other Support links - http://support.microsoft.com/ph/14019#tab13
Posted by Microsoft on 7/11/2012 at 9:26 PM
Thanks for your feedback.

We are rerouting this issue to the appropriate group within the Visual Studio Product Team for triage and resolution. These specialized experts will follow-up with your issue.
Posted by Microsoft on 7/11/2012 at 4:48 AM
Thank you for your feedback, we are currently reviewing the issue you have submitted. If this issue is urgent, please contact support directly(http://support.microsoft.com)
Sign in to post a workaround.