PR# 19005 {EV_WINDOW}.width in Windows does not account for value of GetSystemMetrics (SM_CXFRAME)
Problem Report Summary
Submitter: finnianr
Category: EiffelVision
Priority: Medium
Date: 2014/12/23
Class: Bug
Severity: Serious
Number: 19005
Release: 7.2.9.1351
Confidential: No
Status: Analyzed
Responsible:
Environment: Windows 7
Synopsis: {EV_WINDOW}.width in Windows does not account for value of GetSystemMetrics (SM_CXFRAME)
Description
The value of EV_WINDOW.width in Windows includes 2 times the window border reported by GetSystemMetrics (SM_CXFRAME). The reported width in GTK does not include any such external border. This means that calculations to make a window big enough for a particular component will be incorrect in Windows.
To Reproduce
The results of bad window width calculations are noticeable in components nested in a docking tab. The docking tab will adjust itself to the available window space, but if the inner component is too big, it will be clipped on the right unless the window is the correct size. By adding 2 * GetSystemMetrics (SM_CXFRAME) to the calculated window width, the component will always align perfectly inside the tab regardless of any change in size of the external window border caused by changing the windows theme, for example, using classic XP mode instead of Aero which demonstrably affects the value of GetSystemMetrics (SM_CXFRAME). This I think is proof of the issue.
Problem Report Interactions
I will try setting the window item minimum width instead. It looks like the GTK window might be borderless on Linux Mint, so it made it seem like there was some inconsistency with Windows.
Could you be more specific on the issue? The size of a window always includes its borders to ensure a proper positioning of the window on the desktop. On the other hand, the size of its content can be computed using the size of its item which will naturally expand to the inner side of the window. Is there something we are missing?