I'm currently working on an access control program in C# and I've come across the problem of blocking windows. The original idea I've come up with is rendering a plain black form over the position given by the IntPtr window handle of the process. The problem within that is updating the form's position smoothly and z-index of the position (being I don't want it topmost). I've also noticed a ridiculously high resource use with my solution as I was using a loop to constantly check position.
Thus why I ask: What would be the best solution for this without eating major resources? The entry point is merely the name of the running process.
Presently the idea is only blocking off browsers (IE: a school application to prevent distraction when a lecture is active).
More Information:
I'm not looking to close a window in
my own application, I'm trying to
obscure windows from other processes.
My application is not a
virus/annoying program, it's
essentially meant to prevent uses of
potentially distracting applications
in a school environment. It's made
for lectures in a school computer
lab.
I'm presently pulling the main window
from the process caught by the
process name of browsers.
I can't completely disable the computers either.
I really hate hate hate any application trying to mess around with other application's windows. Sorry, this comes from very deep.
The only thing I can think of that is somewhat sensible is to lock the current user session, and swith the computer to another desktop belonging to another account with no rights to do anything except what's required under the circumstances.
Or if it is acceptable to disable the use of the computers entirely, you could put all the monitors on a single power switch on the teacher's desk.
If you are looking to hide your application window, I can suggest 3 things. First thing, try setting your form's visible property true and calling the hide() method. Second thing is to set your form's transparency to 100%, which will hide it. The third is, maybe consider your application should be a windows service instead of a windows form application.
If you are looking to hide other windows so that your application is always on top, set the TopMost property to true in your form: http://msdn.microsoft.com/en-us/library/system.windows.forms.form.topmost(VS.71).aspx
This might help too: http://www.codeproject.com/KB/cs/windowhider.aspx
[DllImport("user32.dll")]
static extern bool ShowWindow(IntPtr hWnd, int nCmdShow);
static void MinimizeProcess(string procName)
{
foreach (Process p in Process.GetProcesses())
{
if (p.ProcessName == procName)
{
ShowWindow(p.MainWindowHandle,11);
}
}
}
If you have an array of process names you'd obviously want to refactor this to take in an array so that you're not looping through every process for everything you want to minimize, but you get the idea.
You could use the windows api to hide the offending window. user32.showwindow
Not exactly what you've asked for, but might be simpler.
You can do:
this.Hide()
this.Visible = false;
Or if this is the main for you dont want to show, simply dont run the forum when you start the app.
Related
In my WPF application, I have multiple classes each of which implements a message loop. All of these message loops then run in parallel when I create objects of these classes. These objects may show a dialog box at times. The main application thread must keep an eye on these objects and make sure none of them is stuck with the dialog (and press Cancel (Escape key) if it determines such cases). What is the correct way to determine the active foreground window of a thread? I know there is a GetForegroundWindow() API, but it appears as if it works at system level and not thread level.
There's no such thing as the per-thread active foreground window. So what you are explicitly asking for does not have an answer.
Probably the right way to go here, using Win32 at least, is to enumerate top-level windows with EnumWindows. Then use GetWindowThreadProcessId to identify that the window is associated with one of your threads. Finally use GetClassName to identify that the window is a file dialog. Then feel free to do whatever dastardly thing it is you want to do to the window!
On the other hand, this sounds like a perfect candidate for UIAutomation. You are automating testing of UI. UIAutomation will be able to find these file dialog windows and press buttons on them.
I've got a command line application that starts up and does some work. During that time, it listens to keystrokes (s => show status). It's not the typical command prompt where you press 's' and <ENTER> - it's the type which reacts as soon as the key is pressed the status is shown.
Now I'm trying to "control" that command line application from a fancy GUI application by sending keystrokes. I've tried the more conventional approach of writing to the Process' StandardInput but that doesn't seem to have an effect at all. Also, because the actual process doesn't have a window (it's started with CreateNoWindow=true) I can't try the Win32 API for sending keystrokes to a window.
Is there any other way of doing it?
Fancy console applications are problematic.
They have a tendency to directly read the keyboard input, instead of going through stdin. They also have a tendency to directly control their console, instead of going through stdout.
AFAIK, there is no way to programmatically control these apps. If you really, really need to, I would explore something like AutoHotKey controlling the app on a private desktop (AHK uses a virtual keyboard/mouse driver). I'm not sure how you would read the results off the console, though; it may be possible to create an intermediate console app that's started by your program (in the private desktop) and starts the target app. The intermediate app would then share its console with the target app and use low-level I/O to detect changes.
Or you could use Detours to bend the target app to your will.
Well, I seem to have found an answer to my own question.
It's a real "kludged together" solution, but it works - and for all the intents and purposes of the application I'm building, it doesn't matter.
So, what I did was use two WinAPI functions called
static extern bool ShowWindow(IntPtr WindowHandle, int nCmdShow);
static extern bool SetForegroundWindow(IntPtr WindowHandle);
The first one can be used to Show/Hide a window by changing nCmdShow to 1 and 0 respectively. The other one puts the window (determined by WindowHandle) to the front. Combining these two together, I was able to programmaticly bring the console window up front, do a simple SendKeys.Send(); operation and then hide it again.
// Use a WIN API command to bring the command line to front
SetForegroundWindow(workerProcess.MainWindowHandle);
// Send a keystore to re-display the STATUS of the worker
SendKeys.Send("s");
// Hide the window again.
ShowWindow(workerProcess.MainWindowHandle, 0);
Now, it's a real kludge job, but it gets the job done. One potential pitfall would be if a user is using the computer for something else, and would nail that 1 in a 10000000 moment when the window is active with a 'q' - it would quit the worker program. But the application is intended to be used on dedicated machines that most likely won't even have monitors, keyboards or mice attached to them so it wouldn't be an issue.
Thanks to all who answered, since you did - in one way or another, steer me towards the right solution.
I found an even better way to accomplish the functionality without the theoretical risk of causing problems with simultaneous user input and window-switching.
The trick is to use the WinAPI functions called PostMessage to send up KeyDown (or KeyUp) message to the process which does the same thing. No need to bring the process window to the front and hide it immediately afterwards!
I'm sending the key-down command with key 'S' as the argument:
// 0x0100 - VM_KEYDOWN
// 0x0101 - VM_KEYUP
// 0x53 - S-key
PostMessage(workerProcess.MainWindowHandle, 0x0100, 0x53, 0);
PostMessage(workerProcess.MainWindowHandle, 0x0101, 0x53, 0);
I'm trying to control a Java application from my C# program. Before the program begins to input data, it checks if there are any pervious data input windows, and tries to close them.
The code for checking if a window exists is:
public static bool WindowExists(string WindowName)
{
IntPtr hWnd = FindWindow(null, WindowName);
return (hWnd != IntPtr.Zero);
}
Until now, I simply used this method in a while loop (sending Alt+F4 to the windows), until there was no open input window left.
A while ago the Java application got an update, and this method no longer works. For some reason, WindowExists keeps returning true, even after the data input window is closed. This only happens if the input window existed at least once.
I even tried to add Thread.Sleep() to the loop, to make sure this isn't caused by some latency in the Java app, but it didn't work.
Sometimes simply calling WindowExists crashes the input window.
There's no problem with the code, because it has worked before, and it still works with other programs, so it must be a problem with the update in the Java program.
Is there any alternative/more reliable way to check if a window exists?
Changing sending Alt+F4 to "close window event" might also worth a try, but I have no idea how to send this event to another program's window.
I'm a newbie, so please keep the answer simple.
Thanks in advance.
I would use Spy++ to watch the window handle of the Java app, and see if you can figure out what else is going on - I agree there has to be a way to tell that it is closed.
I assume watching the process list is out of the question...
I would hazard a guess that whilst the Java app is running and consequently, the JVM, the 'handle' to the window has not yet been garbaged collected and as such appears to the underlying pointer mechanism as still being valid.
If it was me writing that stuff (and if I was able to change the Java code) I'd probably add a means of querying the java app to see if its windows are showing.
A sockets interface or something.
My guess is that either the window hasn't been completely disposed of by the Java code/VM, or it's handling Alt+F4 in some special way (i.e. maybe making itself invisible rather than closing).
Creation/deletion of windows is out of your control. If you want to reliably detect the presence of 'someone else' using the same resource a you want, have that other party communicate it explicitly.
The other party may signal it's presence by creating a file, opening a port, whatever, and can release/delete/close it on it's exit.
Try to make additional check using IsWindow API, on hWnd value returned by FindWindow.
I have a windows form application which needs to be the TopMost. I've set my form to be the TopMost and my application works as I'd like it to except for in one case.
There is a 3rd party application (referred to as player.exe) that displays SWF movie files on a portion of the screen that popup on top of my application.
Using Process Monitor I determined that player.exe application calls
flash.exe <PositionX> <PositionY> <Width> <Height> <MovieFile>
in my case:
flash.exe 901 96 379 261 somemovie.swf
Since flash.exe is being spawned in a new process after my form has been set to the TopMost it is appearing on top of my application.
First thing I did was make my application minimize the player.exe main application window hoping that this would prevent the Flash from appearing also. But, unfortunately it doesn't... even with the window minimized whenever the flash movie starts it shows up at the pixel location (901,96). I then tried creating a timer to keep setting the form.TopMost property to true every 10ms. This sort of works but you still see a very quick blip of the swf file.
Is there some type of Windows API call which can be used to temporarily prevent player.exe from spawning child processes which are visible? I admit it sounds a little far fetched. But, curious if anyone else has had a similar problem.
Addendum:
This addendum is to provide a reply to some of the suggestions layed out in Mathew's post below.
For the emergency situation described in the comments, I would look at possible solutions along these lines:
1) How does the third party application normally get started and
stopped? Am I permitted to close it
the same way? If it is a service, the
Service Control Manager can stop it.
If it is a regular application,
sending an escape keystroke (with
SendInput() perhaps) or WM_CLOSE
message to its main window may work.
Easiest way to close the app is to CTRL-ALT-DEL, then kill process. -OR-
The proper way is to Hold ESC while clicking the left mouse button... then input your username and password, navigate some menu's to stop the player.
There is no PAUSE command... believe it or not.
I don't think using WM_CLOSE will help since minimizing the application doesn't. Would that kill the process also? If not, how do you reopen it.
2) If I can't close it nicely, am I permitted to kill it? If so,
TerminateProcess() should work.
I can't kill the process for two reasons. 1) Upon relaunch you need to supply username/password credentials... There may be a way to get around this since it doesn't prompt when the machine is rebooted but... 2) Whenever I kill the process in task manager it doesn't die gracefully and asks if you want to send an error report.
3) If I absolutely have to leave the other process running, I would try
to see if I can programmatically
invoke fast user switching to take me
to a different session (in which there
will be no competing topmost windows).
I don't know where in the API to start
with this one. (Peter Ruderman
suggests SwitchDesktop() for this
purpose in his answer.)
I got really excited by this idea... I found this article on CodeProject which provides a lot of the API Wrapper methods. I stopped implementing it because I think that in order for desktop's to work you must have explorer.exe running (which I do not).
EDIT2: On second thought... maybe explorer.exe isn't needed. I'll give it a try and report back.
Edit3: Was unable to get the code in that article working. Will have to put this on hold for a moment.
Answer Summary
As one might have expected, there is no simple answer to this problem. The best solution would be to problematically switch to a different desktop when you need to guarantee nothing will appear over it. I was unable to find a simple C# implementation of desktop switching that worked and I had a looming doubt that I would just be opening a whole new set of worms once it was implemented. Therefore, I decided not to implement the desktop switching. I did find a C++ Implementation that works well. Please post working C# virtual desktop implementations for others.
Setting the TopMost property (or adding the WS_EX_TOPMOST style to a window) does not make it unique in the system. Any number of topmost windows may be created by any number of applications; the only guarantee is that all topmost windows will be drawn 'above' all non-topmost windows. If there are two or more topmost windows, the Z-order still applies. From your description, I suspect that flash.exe is also creating a topmost window.
Aside from periodically forcing your window to the top of the Z-order, I think there is little you can do. Be warned, however, that this approach is dangerous: if two or more windows are simultaneously trying to force themselves to the top of the Z-order, the result will be a flickering mess that the user will likely have to use the task manager to escape.
I recommend that your program not attempt to meddle with other processes on the computer (unless that is its explicit purpose, e.g. a task manager clone). The computer belongs to the user, and he may not value your program more highly than all others.
Addendum:
For the emergency situation described in the comments, I would look at possible solutions along these lines:
How does the third party application normally get started and stopped? Am I permitted to close it the same way? If it is a service, the Service Control Manager can stop it. If it is a regular application, sending an escape keystroke (with SendInput() perhaps) or WM_CLOSE message to its main window may work.
If I can't close it nicely, am I permitted to kill it? If so, TerminateProcess() should work.
If I absolutely have to leave the other process running, I would try to see if I can programmatically invoke fast user switching to take me to a different session (in which there will be no competing topmost windows). I don't know where in the API to start with this one. (Peter Ruderman suggests SwitchDesktop() for this purpose in his answer.)
You can use the Process class to start flash.exe directly - and use an appropriate ProcessStartInfo settings to show the window in a hidden state - or with a WindowStyle of hidden or minimized.
You could also consider using the SetWindowsHookEx API to intercept the process start API calls, and when the process is flash.exe run some code to restore you window to top-most status.
Matthew's answer is excellent, but I suspect you may be asking the wrong question. Why does your application need to be topmost? If you're trying to create a kiosk or some such, then topmost is not the way to go.
Edit: After reading your response to Matthew's comment, I'd suggest creating a new desktop and switching to it before displaying your alert. (See CreateDesktop and SwitchDesktop in MSDN.)
I'm trying to find a way to get the open tasks in C#. I've been searching on google and can only find how to get a list of the processes. I want the only the tasks that would show up on the taskbar.
Also, along with that, it would be cool if I could get the process the task is associated with. And if possible get the thumbnail images that Vista uses for the ALT-TAB menu, like in this image:
I assume that I will have to use pinvokes because it really doesn't look like there are any libraries to do this already. Any ideas?
This article should pretty much tell you exactly what to do, it shows how to build your own task switch and includes the code needed to enumerate all windows and determine if they are "tasks" and it shows you how to use PrintWindow api to get the previews on XP.
http://msdn.microsoft.com/en-us/library/ms997649.aspx
Also, here is a blog post that talks about the algorithm used to determine what shows up in the Alt+Tab view. Basically you need to check the WS_EX_APPWINDOW and WS_EX_TOOLWINDOW along with if the window has an owner.
From an API (Win32) perspective there is no such thing as Tasks (at least not the one that Windows Task Manager/Alt-Tab shows).
Those "Tasks" are actually top level windows.
So in order to get a list of those, you need to enumerate the windows (here is the PInvoke for it).
Then look at the style of the windows to determine if they are actually top level windows.
I haven't tried it, but I suspect something like this:
using System.Diagnostics;
static void MyFunc()
{
Process[] processes = Process.GetProcesses();
foreach(Process p in processes)
{
if (p.MainWindowHandle != 0)
{ // This is a GUI process
}
else
{ // this is a non-GUI / invisible process
}
}
}
The point is to check each process for a WindowHandle.
#abelenky17
I suspect that this will not cover all cases, for example there are processes who have several top level windows (that all appear in the task manager).
Consider for example: FireFox, Windows Explorer, IE, etc... those applications can have multiple windows on the desktop.
Also, it will not handle Terminal Sessions scenario's properly (because you enumerate all the processes running in the system).
#Dan C.
Doing something like this:
p.ProcessName != "explorer"
seems ok to you? It smells, bad.