Check Environment.UserInteractive before showing UI

[vatsan-madhavan]

It doesn't seem to affect WinForms. The checks come from WPF itself.

Perhaps winforms should add these checks 😄 - no point in trying to show ux when Environment.UserInteractive is (genuinely) false.

Originally posted by @vatsan-madhavan in dotnet/wpf#2663 (comment)

[weltkante]

hmm not entirely sure whether these checks add any value, winforms is all about wrapping win32 UI so normally you should just let win32 decide when its capable of showing UI and when not. WPF may be a bit different here because it has its own rendering so it probably needs to have its own independent decisions when UI should be available.

If you add these kinds of checks to WinForms then please do it consistently and don't just arbitrarily reject some APIs but allow others.

[vatsan-madhavan]

so normally you should just let win32 decide when its capable of showing UI and when not

And this is the mechanism ;-)

Win32 primitives don’t all come with all the extra intelligence - callers have to do the work.

Under the hood, Environment. UserInteractive comes from a user32 call about display availability (GetUserObjectInformation(UOI_FLAGS), look for WSF_VISIBLE)

[weltkante]

So, lets say you'd reject common dialogs. What about shell dialogs? What about win32 message boxes? What about modal forms built into winforms? What about user forms shown with a modal loop? What about "please wait" or splash screen popups waiting for a computation instead of user input? Do you generally prevent HWND usage if UserInteractive is disabled?

I'd say if the primitives don't deem it important to prevent running in non-interactive environments then winforms should not be adding arbitrary restrictions, but thats just my opinion, I'm not opposed to throwing exceptions to point out to devs they're doing something wrong. Just seems like a lot of work for little value.

[vatsan-madhavan]

MessageBox, among other primitives, is somewhat special in how it is used. Applications expect it to work reliably under adverse conditions (OOM), from within services etc. (Even though we repeatedly tell developers not to run WPF from within Windows services and that it’s unsupported, they do so anyway; perhaps this happens in the WinForms ecosystem as well? ). IMHO additional precautions would still be valuable for MessageBox than the rest.

[weltkante]

Even though we repeatedly tell developers not to run WPF from within Windows services and that it’s unsupported

The problem is that the borders are fluent: COM - STA - HWND - UI are all interconnected - at which point do you make the cut to "unsupported" and at which point do you actually disallow a primitive when validating UserInteractive in WinForms? Unsupported only means you don't get to ask for bugfixes, not that you aren't allowed to do it, last time I heared about it VS puts the new style project system compiling against Desktop Framework under "unsupported" yet still large parts of the ecosystem rely on it to work.

they do so anyway; perhaps this happens in the WinForms ecosystem as well?

We have one service out of 20 or something that prints daily reports and requires WinForms to work. It already needs to be switched some flag to work in the first place, so it might be that for this service "UserInteractive" would evaluate to true anyways. I don't know the details but I could check.

We don't encourage the usage of that service, but there's certainly demand in running UI code "offscreen" without a user logged on. Some customers want their daily reports printed and mailed automatically without having someone logged on permanently on the machine just so a process can run in UI context. The reporting library is winforms based and putting everything in a service is much easier than writing the interop required to allocate a window station and logon a dummy user via the win32 API (if thats even possible, I know there are APIs for things like this but never tried to do it, you'd basically writing your own service infrastructure with UI support).

Devs are usually trying to solve a problem, declaring a solution "unsupported" doesn't matter, if its the "best" solution the devs can find they'll take it anyways. If you want to avoid that, offer them alternatives to solve their problem, rather than declaring it unsupported.

In general, many common libraries are written with UI context in mind yet there is still occasional demand running them in an automated fashion without having a user sitting in front of a screen. So you usually have the choice on going unsupported or reinvent everything, of course almost nobody can afford to do the latter.

I'm mentioning all that just as a data point since it came up in the discussion, I personally still have no preference over whether winforms should be usable in service context or not.

[merriemcgaw]

Until we have scenarios where this is a problem, I don't think we're going to invest at this time.

[danmoseley]

Happened to notice this. The proposal would not work since as written, both Winforms' UserInteractive impl and the core libraries will return "true" (ie interactive) if GetUserObjectInformationW fails. It will fail on Windows Nano, and thus indicate interactive is true, and Nano certainly doesn't support UI.

https://source.dot.net/#System.Windows.Forms/System/Windows/Forms/SystemInformation.cs,640
https://github.com/danmosemsft/runtime/blob/7a1ff8272bd8afe74ed1b98b8c7d1f6c6a6d2a07/src/libraries/System.Private.CoreLib/src/System/Environment.Windows.cs#L144

I don't know about hte Winforms version, but the Environment API is essentially for code running on regular Windows SKU's to determine whether they are running within a non-interactive Windows Service.

[vatsan-madhavan]

Then WPF may need updates to run on Nano correctly (assuming it's supposed to run on Nano at all.) IIRC WPF relies on E.UserInteractive being reliably correct today.

[danmoseley]

Nano is headless - it isn't intended for UI - I'd be surprised if WPF is intended to work there, but I know nothing about that of course.