On 06/02/2020 20:41, Sergey Bylokhov wrote:
On 2/6/20 12:24 pm, Alexey Ivanov wrote:
I am not sure that this constant is related to the primary monitor
only. The spec for SM_CYBORDER does not mention the primary monitor
like some others SM_CYMAXIMIZED/SM_CYSCREEN etc.
It's stated here:
https://docs.microsoft.com/en-us/windows/win32/gdi/multiple-monitor-system-metrics
The GetSystemMetrics function returns values for the primary monitor,
except for SM_CXMAXTRACK and SM_CYMAXTRACK, which refer to the entire
desktop. …
Then we will need to find some alternatives to GetSystemMetrics which
is used a lot.
I'm afraid there's no alternatives.
GetSystemMetricsForDpi [1] performs the same scaling that we ourselves.
This function returns the same result as GetSystemMetrics but scales it
according to an arbitrary DPI you provide if appropriate.
Available since Windows 10, version 1607.
We may need to take that into account when using the returned values
from GetSystemMetrics.
[1]
https://docs.microsoft.com/en-ie/windows/win32/api/winuser/nf-winuser-getsystemmetricsfordpi
We use this value as-is for all monitors, in java we scale value
and if passed back to native we convert it again by ScaleUpY like in
resetDropDownHeight().
Does it mean ScaleDownY at line 233 is not required then?
The GetTotalHeight() is used at line 316 where the user's space
coordinate are expected.
So my initial understanding was correct.
Looks good.
Or the fact that we scale the value in Java means we have to scale
the value obtained from the native, right?
All values which are obtained from native should be scaled before
using, since
java operates in the user's space coordinates. But we still have lots of
places where this scaling is missing.
--
Regards,
Alexey
