Regression: ::GetSystemMetrics delivers different values - by Peter Schregle

Status : 

  External<br /><br />
		This item may be valid but belongs to an external system out of the direct control of this product team.<br /><br />
		A more detailed explanation for the resolution of this particular item may have been provided in the comments section.


10
0
Sign in
to vote
ID 753224 Comments
Status Closed Workarounds
Type Bug Repros 3
Opened 7/11/2012 4:06:00 AM
Access Restriction Public

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.

Sign in to post a comment.
Posted by jfoegen on 4/23/2015 at 9:02 AM
I have seen this same problem. I thought GetSystemMetrics was an API call that was giving me the current state of what the user had set for his theme and his OS. I did not realize it is just "hard coded" by the compiler. I am using SM_CXFRAME and assumed if the user changed his/her theme where they are using wide themes, these values would be reflected when using the API call. But you are saying it is just based on binary's target header?
Posted by Tanya [MSFT] 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 Alex [MSFT] 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 Thomas [MSFT] 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 Alex [MSFT] 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 Macy [MSFT] 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 Macy [MSFT] 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)