MessageBox
-
MessageBoxes are a UI technology for showing a user some message. Well, that is, when the program which provides the underlying cuase is running on his machine. Things get more complicated when the cause originates somewhere in a windows service. And worse yet, when the service is running on a different machine.
Since several versions of Windows, there is so-called "Session 0 isolation": services run in session 0 and cannot interact with the UI even if a user is logged in - in contrast to older versions like Windows 95.
Now we are in the year 2018, and we equip the machines we sell to our customers with Windows 10.Comes Kevin who tries to solve a problem in a class used in WCF communication. When the socket is already in use by another application (or another instance of the application), an error occurs. He now decided to use following approach:
if (MessageBox.Show("An error occured blah blah blah....") != MessageBoxResult.Yes) ...Things will surely become great when that class is used with contexts other than a UI application...
-
@BernieTheBernie said in MessageBox:
Things will surely become great when that class is used with contexts other than a UI application...
I remember freezing up an SSIS server by having a package pop a dialog box from within a script component. Fun times...
-
Looks like DRC rules are missing as part of the validated commit process....
-
@berniethebernie Windows used to actually create a new blank desktop for stuff like this, let you switch to it to see the dialog, then deleted it when you switched back. It was pretty amazing.
I dunno if that's still in Windows 10 or not. Or it might depend on the app's compatibility level.
-
@blakeyrat I think it still does, but no longer allows you to switch to it.
-
@BernieTheBernie said in MessageBox:
Things will surely become great when that class is used with contexts other than a UI application...
Too bad there isn't a way to take those events, and log them-- you could even separate them into information, error and warnings. Maybe attach some additional information and priority to them.
-
@blakeyrat said in MessageBox:
I dunno if that's still in Windows 10 or not. Or it might depend on the app's compatibility level.
- In Windows Vista and 7, everything works as you describe.
- In Windows 8/8.1, the ability to switch to the session was disabled, but could be re-enabled by changing a registry setting.
- In Windows 10 up through build 1803, editing the setting let you switch to the session, but you couldn't interact with it -- mouse and keyboard activity was discarded "for security reasons".
- In Windows 10 build 1803, the session still exists, but the ability to switch to it has been completely removed. There's some third-party software that lets you in, but it requires booting with driver signing enforcement disabled.
-
@Lorne-Kates said in MessageBox:
Too bad there isn't a way to take those events, and log them-- you could even separate them into information, error and warnings. Maybe attach some additional information and priority to them.
The .NET 2.0 way to do that required administrator privileges at install time, and at first run if no one told the installer to register the event sources.
The .NET 4.0 way to do that doesn't actually log anything unless you use some arcane command-line stuff to launch the app, which you can't do with services.
-
@Lorne-Kates said in MessageBox:
@BernieTheBernie said in MessageBox:
Things will surely become great when that class is used with contexts other than a UI application...
Too bad there isn't a way to take those events, and log them-- you could even separate them into information, error and warnings. Maybe attach some additional information and priority to them.
Too bad the Windows library that generates the default dialog UI doesn't do that automatically when a non-interactive process tries to use one.
-
@TwelveBaud said in MessageBox:
The .NET 2.0 way to do that required administrator privileges at install time, and at first run if no one told the installer to register the event sources.
Yeah but you're talking about a Service; you already need admin to install it, and you already have a nice neat .NET installer class that can register event sources.
-
@anotherusername said in MessageBox:
Too bad the Windows library that generates the default dialog UI doesn't do that automatically when a non-interactive process tries to use one.
Windows generally assumes programs aren't written by morons. (It's a wrong assumption most of the time. Raymond Chen has written a bunch of articles about stuff they had to change/fix because they'd originally assumed software developers weren't morons and it turns out oops.)
-
@blakeyrat Windows generally assumes programs are written by morons, and adds hacks and aliases so that programs written by morons can sometimes still work as intended. Raymond Chen has written a bunch of articles about stuff they had to change/fix because they'd originally failed to predict a way that software developers would be morons and use Windows libraries in a way that made things break.
But really, though, if your library displays a blocking dialog window, and doesn't bother to check whether it has an interactive desktop to do so on and provide a safe fallback, that's a shortcoming of your library. And it's a pretty good example of a case where Windows should really change/fix its library function because they'd originally failed to predict that software developers would be morons by calling it in that case. I mean hell, it's already got an event logging system built-in; it could just hook into that.
-
@anotherusername said in MessageBox:
@blakeyrat Windows generally assumes programs are written by morons, and adds hacks and aliases so that programs written by morons can sometimes still work as intended.
Well ok it does now, it didn't when it was originally written.
Whatever, me stupid wrong moron etc. I posted a thing, make sure you post a thing that says I'm dumb and wrong, yeah, yeah we get it.
@anotherusername said in MessageBox:
And it's a pretty good example of a case where Windows should really change/fix its library function because they'd originally failed to predict that software developers would be morons by calling it in that case.
How could they?
-
@blakeyrat said in MessageBox:
Well ok it does now, it didn't when it was originally written.
The side effects aren't always evident when code is originally written. The broken ways that people will use it aren't always evident either. But still, Microsoft has attempted to go back and patch things when that's possible.
How could they?
At the time, they certainly couldn't, since they hadn't even developed the concept of elevated processes, much less create separate workspaces for them. But at the point where they did start sandboxing elevated processes in separate workspaces, they could've predicted that sandboxed processes might need some workarounds. In fact, they did predict this, which is why they originally designed it so the user could switch to the sandbox environment to dismiss dialog boxes.
-
@anotherusername But Services aren't elevated, and AFAIK shared libraries have no way of knowing if they are running in a Service or an application.
So your Service calls MessageBox. How does MessageBox know it's being called from a Service? How does it know it has no desktop to display onto?
-
@blakeyrat If there's really no way for the code tell whether it even has a desktop to display its window on (where the user can interact), then that's TRWTF.
-
@anotherusername said in MessageBox:
@blakeyrat If there's really no way for the code tell whether it even has a desktop to display its window on (where the user can interact), then that's TRWTF.
What is wrong with System.Environment.UserInteractive
-
@TheCPUWizard said in MessageBox:
System.Environment.UserInteractive
I guess that would work for the .NET version of MessageBox. I dunno, maybe it's a non-issue. I just wasn't aware of any way that any library code could tell whether the app running it had a GUI.
-
@blakeyrat said in MessageBox:
@TheCPUWizard said in MessageBox:
System.Environment.UserInteractive
I guess that would work for the .NET version of MessageBox. I dunno, maybe it's a non-issue. I just wasn't aware of any way that any library code could tell whether the app running it had a GUI.
How do I detect that my application is running as service or in an interactive session?
I'm writing an application that is able to run as a service or standalone but I want to detect if the application was executed as a service or in a normal user session.
-
@blakeyrat said in MessageBox:
@TheCPUWizard said in MessageBox:
System.Environment.UserInteractive
I guess that would work for the .NET version of MessageBox. I dunno, maybe it's a non-issue. I just wasn't aware of any way that any library code could tell whether the app running it had a GUI.
I'm wondering why a library would pop a messagebox in the first place... Shouldn't it be the caller's responsibility to do a messagebox or log or signal flare or whatever? It smells wrong to have a library jumping straight to that IMO
-
@sloosecannon said in MessageBox:
I'm wondering why a library would pop a messagebox in the first place.
Now we're back to discussin the morons who are writing software.
-
@sloosecannon said in MessageBox:
I'm wondering why a library would pop a messagebox in the first place...
It shouldn't. Even libraries that GUARANTEE GUI availability (say, WinForms) shouldn't dictate how their clients express errors.
-
@blakeyrat said in MessageBox:
It shouldn't. Even libraries that GUARANTEE GUI availability (say, WinForms) shouldn't dictate how their clients express errors.
I sort of agree. I certainly agree that clients of the library should be able to say exactly how they want to express errors, but there are cases where it's acceptable to provide a default mechanism (provided it is easy to override, of course) to avoid the other case: errors just getting swallowed with no reporting at all. Which is definitely how some people seem to want to write code despite it being the very worst of the worst of ideas for programming…
-
@dkf said in MessageBox:
@blakeyrat said in MessageBox:
It shouldn't. Even libraries that GUARANTEE GUI availability (say, WinForms) shouldn't dictate how their clients express errors.
I sort of agree. I certainly agree that clients of the library should be able to say exactly how they want to express errors, but there are cases where it's acceptable to provide a default mechanism (provided it is easy to override, of course) to avoid the other case: errors just getting swallowed with no reporting at all. Which is definitely how some people seem to want to write code despite it being the very worst of the worst of ideas for programming…
Thus exceptions... if the client (aka something up the call stack) does not "do something" the application promptly terminates...
-
This reminds me of a few libraries my communist coworker wrote which popped up MessageBoxes when an error was encountered... even when called from an ASP.NET website. Luckily it is mostly fixed now.
-
@blakeyrat said in MessageBox:
Windows generally assumes programs aren't written by morons.
They should stop because they know it's not true.
-
@ben_lubar said in MessageBox:
@blakeyrat said in MessageBox:
Windows generally assumes programs aren't written by morons.
They should stop because they know it's not true.
Do they though?
-
@blakeyrat said in MessageBox:
Whatever, me stupid wrong moron etc. I posted a thing, make sure you post a thing that says I'm dumb and wrong, yeah, yeah we get it.
-
@Tsaukpaetra said in MessageBox:
@blakeyrat said in MessageBox:
@TheCPUWizard said in MessageBox:
System.Environment.UserInteractive
I guess that would work for the .NET version of MessageBox. I dunno, maybe it's a non-issue. I just wasn't aware of any way that any library code could tell whether the app running it had a GUI.
How do I detect that my application is running as service or in an interactive session?
I'm writing an application that is able to run as a service or standalone but I want to detect if the application was executed as a service or in a normal user session.
-
@Jaloopa said in MessageBox:
@Tsaukpaetra said in MessageBox:
@blakeyrat said in MessageBox:
@TheCPUWizard said in MessageBox:
System.Environment.UserInteractive
I guess that would work for the .NET version of MessageBox. I dunno, maybe it's a non-issue. I just wasn't aware of any way that any library code could tell whether the app running it had a GUI.
How do I detect that my application is running as service or in an interactive session?
I'm writing an application that is able to run as a service or standalone but I want to detect if the application was executed as a service or in a normal user session.
Yeah, I've found that an App started from the crash recovery thing doesn't have the same working directory as you'd expect, and a plugin I'm using is not okay with that. Stupid library...
The Old New Thing
