Author |
Topic: System metrics (Read 1448 times) |
|
RNBW
New Member
member is offline
Gender: 
Posts: 19
|
 |
System metrics
« Thread started on: May 25th, 2015, 09:18am » |
|
I've just been looking at System Metrics and using the following code:
Code:
SYS "GetSystemMetrics", 0 TO xscreen%
SYS "GetSystemMetrics", 1 TO yscreen%
PRINT "xscreen% = "; xscreen%
PRINT "yscreen% = "; yscreen%
I get:
xscreen% = 1280
yscreen% = 720
whereas my screen resolution is 1920 x 1080.
Is there a limitation on GetSystemMetrics?
???
|
|
 Logged
|
|
|
|
rtr2
Guest
|
|
Re: System metrics
« Reply #1 on: May 25th, 2015, 11:04am » |
|
on May 25th, 2015, 09:18am, RNBW wrote:| Is there a limitation on GetSystemMetrics? |
|
No (did you really think there might be?). Your system is working exactly as it should.
Recent versions of Windows automatically scale a high-DPI display so that it 'appears' to applications to be 96 DPI. This improves compatibility with applications written before such displays were commonplace.
The figures you have quoted (actual resolution 1920x1080, scaled resolution 1280x720) imply that your display's native DPI is 1920/1280*96 = 144 DPI, which is well above what many programs are designed to work with.
If you really don't want the scaling to be applied you can disable it either in the program's Compatibility settings (Properties... Compatibility... Disable display scaling on high DPI settings), in code (SetProcessDPIAware API), or by attaching an appropriate manifest.
But I would caution that if you do that some of the supplied BB4W example programs will not display correctly (or will be too small to read comfortably), and programs you write yourself will need to adapt correctly to high DPI settings.
Richard.
|
| « Last Edit: May 25th, 2015, 11:19am by rtr2 » |
Logged
|
|
|
|
RNBW
New Member
member is offline
Gender:
Posts: 19
|
|
Re: System metrics
« Reply #2 on: May 25th, 2015, 1:01pm » |
|
Richard
Thank you for the explanation. I couldn't find Microsoft's explanation of this, but no doubt it is hidden deep in their documentation. It would be useful if it was made clear. I don't believe there are many modern computers with 1280x720. Most of the budget ones I've seen have 1368x768. However, I can see the need for a standard.
Ray
|
|
Logged
|
|
|
|
rtr2
Guest
|
|
Re: System metrics
« Reply #3 on: May 25th, 2015, 4:44pm » |
|
on May 25th, 2015, 1:01pm, RNBW wrote:| I don't believe there are many modern computers with 1280x720. Most of the budget ones I've seen have 1368x768. |
|
I think you have misunderstood the purpose of the scaling. The 'standard' Dots Per Inch value has always been 96, right back to Windows 95 if not before. That is the value many programs expect, and they will often not work satisfactorily at any other DPI value.
So the automatic scaling built into recent versions of Windows scales not to some arbitrary DPI value, which wouldn't really be useful at all, but to 96 DPI. Therefore because your 1980x1080 display has a native DPI value of 144, the resulting 'scaled' display is necessarily 1280x720.
The fact that a native display resolution of 1280x720 is uncommon (or not) is irrelevant, it is the resolution that results from scaling your display to 96 DPI. Scaling to any other resolution would be pointless.
Richard.
|
|
Logged
|
|
|
|
KenDown
Full Member
member is offline
Posts: 181
|
|
Re: System metrics
« Reply #4 on: Sep 27th, 2015, 9:17pm » |
|
How very odd. I use the same code and get 1920x1080. I'm still using XP, but I haven't noticed any odd results on my 7 and Vista laptops. Which version of Windows are you using?
Also, this is the code I use (and which I got from somewhere else, because I havent a clue what the first two SYS calls do). Is it possible that the first two calls have something to do with it? You might care to try them rather than just the second two calls.
REM These two calls set up the SystemMetrics
SYS"GetWindowLong",@hwnd%,-16TOws%
SYS"SetWindowLong",@hwnd%,-16,ws%AND&FFFBFFFF AND&FFFEFFFF
REM These calls give you the screen dimensions in graphics units, not Windows units
SYS"GetSystemMetrics",0TOscreenx%
SYS"GetSystemMetrics",1TOscreeny%
|
|
Logged
|
|
|
|
RNBW
New Member
member is offline
Gender:
Posts: 19
|
|
Re: System metrics
« Reply #5 on: Sep 27th, 2015, 10:11pm » |
|
The code I used previously was used under Windows 8.1. I have now upgraded to Windows 10 and I still get the same result.
I tried using the following code:
Code:
REM These two calls set up the SystemMetrics
SYS"GetWindowLong",@hwnd%,-16TOws%
SYS"SetWindowLong",@hwnd%,-16,ws%AND&FFFBFFFF AND&FFFEFFFF
REM These calls give you the screen dimensions in graphics units, not Windows units
SYS"GetSystemMetrics",0TOscreenx%
SYS"GetSystemMetrics",1TOscreeny%
PRINT "xscreen% = "; screenx%
PRINT "yscreen% = "; screeny%
and I still get the same result 1280x720
I am using a Lenovo laptop 1920x1080.
|
|
Logged
|
|
|
|
KenDown
Full Member
member is offline
Posts: 181
|
|
Re: System metrics
« Reply #6 on: Sep 28th, 2015, 04:38am » |
|
Oh well, then I'm afraid I don't know and can only accept Richard's reply and solution. I'm grateful to you for flagging up the problem, as otherwise I might come across it sometime and beat my brains out over it.
The only comment I would make is that rather than alter the DPI, with the attendant problems Richard mentions, it might be better just to introduce a scaling factor into your program (assuming, that is, that you have no commercial use for the program and are writing for your own use and benefit).
|
|
Logged
|
|
|
|
|
