There exist 3 descriptions of the display area in TScreen: Screen (Width and Heigth), Desktop and WorkArea. The Delphi description of the difference is quite vague. The Lazarus implementation seems to assume: Screen = primary monitor
WorkArea = primary monitor excluding e.g. TaskBar (SPI_GETWORKAREA) Desktop = entire virtual display, including all monitors

Is this correct?

About the DesktopRect and WorkAreaRect, the WorkAreaRect contains the BottomRight coordinates, while DesktopRect contains the Width and Height in BottomRight. This may be Delphi compatible, but looks very confusing.

No Rect (or Top, Left) properties exist for the Screen. Delphi assumes (0,0) for the primary monitor origin - does this hold for non-Windows platforms?

The same for the WorkArea, where e.g. a Linux taskbar can (and typically does) span multiple monitors. I'm missing a property describing the entire WorkArea, across all monitors, excluding the system areas.

DoDi

07.11.2011 12:42, Hans-Peter Diettrich ?????:

Yes

About the DesktopRect and WorkAreaRect, the WorkAreaRect contains the BottomRight coordinates, while DesktopRect contains the Width and Height in BottomRight. This may be Delphi compatible, but looks very confusing.

You understood the code wrong: Bounds() and Rect() are different functions. Look at it after r33405.

No Rect (or Top, Left) properties exist for the Screen. Delphi assumes (0,0) for the primary monitor origin - does this hold for non-Windows platforms?

Delphi does not assumes anything. It gives you screen width and screen height. (0,0) is assumend by you.

If you need monitor area you can obtain it using PrimaryMonitor or Monitors[] property.

The same for the WorkArea, where e.g. a Linux taskbar can (and typically does) span multiple monitors. I'm missing a property describing the entire WorkArea, across all monitors, excluding the system areas.

WorkArea is retrieved using SystemParametersInfo(SPI_GETWORKAREA).

From MSDN: Retrieves the size of the work area on the primary display monitor. The work area is the portion of the screen not obscured by the system taskbar or by application desktop toolbars. The pvParam parameter must point to a RECT structure that receives the coordinates of the work area, expressed in virtual screen coordinates.

Best regards,
Paul Ishenin.

I cannot see "Bounds" here?

Look at it after r33405.

Thanks for the fix :-)

D7 OH on TScreen.DesktopRect states that the origin of the primary monitor is (0,0), that's why (Screen) Top, Right and Rect could be omitted. But I'm not sure whether that assumption holds for non-Windows displays.

If you need monitor area you can obtain it using PrimaryMonitor or Monitors[] property.

Right, but I wanted to know how all that should be documented.

DoDi

Hans-Peter Diettrich wrote

> You understood the code wrong: Bounds() and Rect() are different > functions. I cannot see "Bounds" here?

There was Bounds(Left, Top, Width, Height)

> Look at it after r33405. Thanks for the fix :-)

The fix do the same as before using a bit another code.

D7 OH on TScreen.DesktopRect states that the origin of the primary monitor is (0,0), that's why (Screen) Top, Right and Rect could be omitted. But I'm not sure whether that assumption holds for non-Windows displays.

It states this only for *single*-monitor systems.
http://docwiki.embarcadero.com/VCL/en/Forms.TScreen.DesktopLeft

> If you need monitor area you can obtain it using PrimaryMonitor or > Monitors[] property. Right, but I wanted to know how all that should be documented.

You don't need to write anything about Screen left,top if Screen has width and height.

Best regards,
Paul Ishenin.

Hans-Peter Diettrich wrote

Right, but I wanted to know how all that should be documented.

You can use seealso to link it to PrimaryMonitor and Monitors[]

Before that I need to know what is related to the primary monitor, and what is related to the entire (virtual) desktop. I cannot test the implemented behaviour, because most of my development systems run in virtual machines, with only one (virtual) monitor.

DoDi