1

Sucessfully using the .NET class Screen in a background thread in a WinForms application, I wondered wether this is well-defined behavior.

I'm currently reading the pixel dimensions of the primary screen like:

var w = Screen.PrimaryScreen.Bounds.Width;
var h = Screen.PrimaryScreen.Bounds.Height;

The reason why I'm wondering is that the WinForms classes tend to be used from the foreground thread only, and I found no documentation stating whether the Screen class is safe from using in a background thread or not.

So my question is:

Is it OK to read the Screen.PrimaryScreen.Bounds property in a background thread?

Update 1:

Please note that my question is not about thread-safety. It is about accessing UI elements from a background thread.

E.g. using ILSpy I found that the methods internally use ReleaseDC which might be disallowed or caused undefined results when being called from a background thread.

Update 2:

Thanks for downvoting and flagging to close this question.

I still do think that this might be non-obvious, since:

  • A background thread has no message pump and the Screen class might require one.
  • The class lives in the System.Windows.Forms assembly which might indicate it requires special attention.
Uwe Keim
  • 39,551
  • 56
  • 175
  • 291
  • 1
    It is read-only, so I see no reason why not – TaW Sep 12 '14 at 17:40
  • Uhm there is the section `Thread Safety` in the same link you have posted. However, not every WinForms classes are unsafe in a background thread. – Steve Sep 12 '14 at 17:42
  • Funny: _Any public static (Shared in Visual Basic) members of this type are thread safe. Any instance members are not guaranteed to be thread safe._ Now `Bounds` isn't but `GetBounds()` is. – TaW Sep 12 '14 at 17:44
  • PrimaryScreen is static – Steve Sep 12 '14 at 17:46
  • @TaW 99.99% of all of the types in .NET say the exact same thing. That tells you basically nothing about how you should be using the type. – Servy Sep 12 '14 at 17:46
  • Please note that my question is _not_ about thread-safety! It is about accessing UI elements from a background thread. – Uwe Keim Sep 12 '14 at 17:46
  • @Steve And the members of the returned object are not, so it merely begs the question of whether the object returned from `GetBounds` can be accessed safely. – Servy Sep 12 '14 at 17:47
  • @UweKeim Which is a virtually identical question. The whole point of marshaling UI objects to the UI thread is to make them thread safe, because they wouldn't be if you didn't. – Servy Sep 12 '14 at 17:47
  • `Screen` doesn't inherit from `Control` so why would they be related? – jamesSampica Sep 12 '14 at 17:49
  • Well, the thing is. The Screen class is an UI object? It doesn't derive from Control so perhaps the rules for that class cannot be applied here – Steve Sep 12 '14 at 17:50
  • 1
    Screen isn't a UI object. It doesn't have any visual representation. – jamesSampica Sep 12 '14 at 17:54

1 Answers1

4

You cannot trust the .NET thread safety documentation, it is merely copy/pasta that was only ever is modified when it really mattered. The most important property of a monitor is that it doesn't jump around on you. There is no read-modify-write at play.

Using it in a thread is fine, the class is a very thin wrapper around the MonitorFromXxx() winapi functions. The underlying DeviceIoControl calls are always safe, device drivers need to keep many processes happy. Actually using the results in a meaningful way, well, maybe not.

Hans Passant
  • 922,412
  • 146
  • 1,693
  • 2,536