I'm a big fan of taking control of every possible situation on the computer when it comes to making apps. And now that I'm beginning to use favor WPF over WinForms for some things, I'm also beginning to realize that many really cool things are missing in WPF - and searching for alternatives seems to be a never-ending struggle.
Is there an alternative in WPF to e.CloseReason for WinForms?
The different "reasons" manifest as separate events. The Closing and Closed events are related to explicitly closing a window, either programmatically or via Alt+F4 or the close button. The Application.SessionEnding event happens at a shutdown or logoff, and information is exposed by ReasonSessionEnding. The exit code from the process can be read from ApplicationExitCode of the Application.Exit event.
The idea is to do something like what a keystroke catcher does, but with multiple input devices. I want a window to record input from devices even if the focus is on another window. What libraries or methodologies would allow me to accomplish this?
This is typically handled via a low level Hook. There is no C# library which will handle this directly, though there is a Microsoft KB article showing How to set a Windows hook in Visual C# .NET.
I am writing an application in c# to lock or freeze all programs untill user enters a value in the app's textbox and clicks ok.
The purpose of the app would be to get people to enter their time.
As far as I know you can set it to top most but they can end the app with task manager so am stuck here..
formName.TopMost = true;
Any help would be appreciated
Yes, that's correct. The Windows operating system allows multiple programs to run at one time. What you're experiencing is entirely by design.
If I remember correctly, the TopMost property applies only to windows in your process, and as you mention, it's all quite irrelevant: the user can still kill your application using the Task Manager.
There's no legitimate way of getting around that. It's not a "limitation", it's a feature. Any app that prevents itself from being closed by the Task Manager is treading dangerously closely on the category of software that we call malware. Nothing good can come out of pursuits like this.
Relevant reading: The arms race between programs and users
Perhaps a good compromise solution is to make your window/form actually top-most and disable the Close button so that the user knows they shouldn't try and close it. This is almost always enough to stop a user that is not determined to end your application by any means necessary, and that's about all you should ever be concerned with.
See the sample code here for how to make your window/form always appear on top of other running applications by setting the WS_EX_TOPMOST flag or toggling HWND_TOPMOST.
I've also already written a detailed answer here about disabling the Close button the correct way by setting the CS_NOCLOSE class style.
How to show messagebox dialog which will not allow user to switch to another window as long as that dialog is not closed like shutdown dialog in windows XP using VB.NET or C# windows application
You can't easily prevent interaction with other applications even from a system-modal message box.
One option is to display a large transparent window behind your message box with the WS_EX_TOPMOST window style. That way it would appear that the other windows are interactive, but clicks would hit your transparent window instead.
You couldn't prevent Control+Alt+Delete though and you'd have to take extra steps to prevent Alt+Tab and such. Also other topmost windows could still compete for the top.
In other words, it's a pain to do and for good reason. As Raymond Chen would say, you may have the most awesome and important application in the world but if it were easy then all of the other applications that aren't as awesome and important as yours would be able to abuse it.
What you're looking for is called a system-modal dialog. This is in contrast to the more typical application-modal dialog, which only prevents the user from doing anything else in your application until they dismiss the dialog. A system-modal dialog extends this prohibition to the entire system and prevents the user from doing anything else at all with their computer until they've dismissed your dialog.
This was possible under 16-bit Windows (versions 3.x and earlier), but this functionality was removed when 32-bit Windows rolled onto the scene (as far back as Windows 95 and NT 3.5). Presumably, there were some vaguely more technical reasons that this capability was now denied to application programmers, but its absence also meant the end to widespread abuse of this feature by developers who thought their application was the only important thing the user could possibly be doing on their computer. (Some of those "vaguely more technical reasons" are related to better support for multitasking and the obsolescence of the "one program—one focus" paradigm.)
Raymond Chen answers the question definitively in a forum post made to this thread:
Win32 doesn't have system modal dialogs any more. All dialogs are modal to their owner.
If you want to simulate such functionality now (and it's highly recommended that you not do so, because it wasn't good programming practice before, and it's particularly alien to users now), you'll have to rely on a hack. This means your solution won't be fool-proof and could be easily bypassed by a knowledgeable or experienced user.
My recommendation is to seriously re-consider your need to prevent the user from switching to another application while a dialog box is visible in your application. System-modal dialogs are a contradiction with today's modern multitasking environments, and there are only extremely limited circumstances where they make sense. Most of those circumstances are limited to the operating system (the shutdown dialog from your example, UAC prompts from Windows Vista/7), rather than individual applications. See if you can't settle for the expected and less user-hostile application modal dialog instead, which you can get easily in C# and VB.NET using the ShowDialog method.
Okay I've spent the afternoon researching and haven't had much luck finding the answer to this. I am trying to prevent an application from launching via some sort of dll or background application. It is to be used in monitoring application usage and licenses at my institution. I have found leads here regarding WqlEventQuery and also FileSystemWatcher. Neither of these solutions appear to work for me because:
With WqlEventQuery I was only able to handle an event after the process was created. Using notepad as a test, notepad was visible and accessible to me before my logic closed it. I attempted to Suspend/Resume the thread (I know this is unsafe but I was testing/playing) but this just hung the window until my logic finished.
With FileSystemWatcher I was not able to get any events from launching a .exe, only creating, renaming and deleting files.
The goal here is to not let the application launch at all unless my logic allows it to launch. Is this possible? The next best solution I came up with was forcing some type of modal dialog which does not allow the user to interact with anything, once the dialog is closed the application is killed. My concern here is killing the application nicely and handling applications with high overhead when they load such as Photoshop or something. This would also interfere with a feature I was hoping to have where the user could enter a queue until a license is available. Is this my best route? Any other suggestions?
Thanks
edit: To clarify this is not a virus or anything malicious. It's not about preventing access to a blacklist or allowing access through a whitelist. The idea is to check a database on a case by case basis for certain applications and see if there is a license available for use. If there is, let the app launch, if not display a dialog letting the user know. We also will use this for monitoring and keeping track if we have enough licenses to meet demand, etc. An example of one of these apps is SPSS which have very expensive licenses but a very limited pool of people using it.
Could you use
System.Diagnostics.Process.GetProcessesByName
in a loop to look for the process?
It might work if you don't use too aggressive a polling rate.
You are indeed close, take a look at the WMI Management Events. http://msdn.microsoft.com/en-us/library/ms186151%28VS.80%29.aspx
Sample code from Microsoft: http://msdn.microsoft.com/en-us/library/ms257355(VS.80).aspx
Subscribing to the appropriate event will provide your application with the appropriate information to perform what you described.
Not sure if this is a GOOD solution but you could do something like pass a key into main so that if the key is not present or valid the application shuts down. Then when you open the application in your code, just pass the key in. Someone would then have to know the key in order to start the application.
This is assuming you have access to the application in question's source code, which upon reading your question again, I'm not so sure of.
I assume you don't have source for the application you want to prevent from loading...
Have you considered using a system policy? That would be the best-supported way to prevent a user from launching a program.
You could have a service running that force-kills any app that isn't "whitelisted", but I can't say how well that would work.
I wonder if you are taking the wrong approach. Back in the day there was a Mac app that would prevent access to the desktop and had buttons to launch a set list of applications.
IDEA
What if you had a wrapper for the approved apps then only allow your wrapper to run on the computer?
I would expect there is some way of hooking an application launch, but can't help directly on that front.
You may be able to improve your current approach by detecting the application's window opening and hiding it (move it offscreen) so that the user can't attempt to interact with it while you are trying to shut it down.
However, another approach that may be possible (depending on your circumstances) would be to write an application launcher. This simply is a replacement for the shortcut to the application that checks your licencing conditions, and then does a Process.Start to launch the real .exe at that point. This would work well for any application. (I used a system like this for starting up applications with specialised environment settings and it works beautifully)
You could combine this with your current approach as a fall-back for "clever" users who manage to circumvent your launcher.
If my understanding is right you want to create an application what will prevent the computer user to start any other process except ones for a white-list.
If this is the case, monitor the process list of processes (in a while loop) using System.Diagnostics.Process (the GetProcesses method gives the list of all running ones)
Just kill the process when it starts.
Or if your machines have Windows 7 (Windows 2008??) you can use AppLocker. http://www.microsoft.com/windows/enterprise/products/windows-7/features.aspx#applocker Just let Windows prevent the startup.
You might want to look at this product: http://www.sassafras.com/licensing.html Personally I can't stand it, but that's because it does what you describe. Might save you some coding.
You could actually edit the registry so when you click a psd, your launcher gets called instead of photoshop. Your launcher then checks for licenses and if there is one starts photoshop with the path of the file.
This is a long shot but you may find it helpful.
Perceived Types and Application Registration
http://msdn.microsoft.com/en-us/library/cc144150(VS.85).aspx