Is there anyway to set a program to be unresponsive in windows?
I have python code that starts a program. But when the program becomes unresponsive i want to do some specific clean up task.
But how do I test it. Because currently it is random.
Is there a way to either make a small program that I can force to be unresponsive?
Or force a running program to be unresponsive.
An "unresponsive" program is typically a GUI application that's blocked on it's main (UI) thread such that it hasn't pumped messages in a long time. That is, the UI feels "frozen" when you try to interact with it and/or the window doesn't seem to repaint itself as it should.
You can easily simulate this by creating a Windows Forms app in C# or Win32 GUI app in C++ using the default project templates in Visual Studio. Or basically any UI framework like Qt for that matter. Then introduce a very long sleep statement (several minutes) in response to a button click.
I don't think the "unresponsive" attribute applies to services, console applications, or background tasks.
Use Alt + Tab keyboard shortcut to bring your unresponsive program to the front, and then press Alt + F4 keys at the same time to force the program to quit.
Related
I'm a developer and a long-time Windows user with an obsession about making my system as convenient to use as possible.
Yesterday I thought about something that has always annoyed me in Windows and that I've taken for granted, and I realized that I have a better idea for how it could work, and I'm now wondering whether it's possible to tweak Windows to work like that.
The thing that annoys me is when windows steal focus. For example, I could be running an installer for some program. While it's working, I'll switch to my browser and browse, maybe entering some text into an email in my browser. Then suddenly the installer finishes and its window steals the focus. Now I'm in the middle of writing an email, so I might press a key that happens to be bound to a button on that installer, and then that button gets invoked, doing some action that I never intended to happen!
This is doubly annoying to me because I'm using a multiple-desktop program called DexPot, and when a window steals focus, it also brings itself to the desktop I'm currently on, which can be really annoying, because then I have to put it back into its original desktop.
How my ideal solution to this problem would work: Every time a window tries to steal focus, we intercept that, and don't let it. We show something like a toaster message saying "Foobar installer wants focus, press Win-Whatever to switch to it". If and when you press the key combo, it switches to the window.
The question is: Is there an easy way to tweak Windows to make this happen? I know very little about Windows programming. I do know AHK and if it's possible with that, that'd be great.
No, there isn't an easy way to add this behavior, but Windows tries to do this automatically.
In theory apps shouldn't be able to steal the foreground while you're actively using another app. Unfortunatly there are some scenarios where Windows can't tell the difference between legitimate user actions that should change the foreground and unwanted foreground-theft. The window manager generally tightens up the holes a bit with each new version of Windows, but also needs to make sure that apps can come to the foreground when the user wants them to, even if that desire is expressed indirectly.
For example, a process launched by the current foreground process can put a window into the foreground. This is necessary so that when a user launches a window from Explorer the newly launched process can open its main window. This permission only lasts until the next user input, so if an application is slow to launch and you start working on an email the app may lose its foreground permissions before it can use them.
See the SetForegroundWindow function documentation for a list of requirements for a process to be able to set a window into the foreground.
There are also apps which specifically make use of these requirements to steal the permission (by joining the foreground queue or synthsising user input to themselves), but I suspect in your installer scenario it is accidental.
I'm not sure what exactly is going on, but I suspect that the problem comes from the installer running as a service and accidentally stealing the foreground permission when it tries to launch the app on your current desktop.
It would be theoretically possible for an external process to hook into the foreground system to override this and show your confirmation toast, but it would be tricky to get right and would require significant low level code (I'd probably start with a CbtHook). It would not be possible in a scripting package like AHK (assuming you mean AutoHotKey) but would need to be native C/C++ code injected into every running process.
On Microsoft Windows (8), I would like to start a process, and prevent it from showing any windows at all. Alternatively, to force-close any windows that are shown. Is there a way to do this?
My application is this: I'm running an automated (nunit) test suite on my continuous integration (teamcity) server. The code under test is also used by an interactive application. Developers occasionally slip in a dialog with a user prompt, without realising what they are doing. This causes the CI process to stop, waiting for user input which never comes. I'd like to be able to dismiss any dialog that appears, or prevent them from being shown.
Even better would be to force an exception at this point, so that the test would also fail.
In my case, this is a C# application, and the dialogs shown are Windows Forms or WPF dialogs.
I did find a couple of similar questions. However each turned out to be solving a slightly different problem.
Stop a process from showing a window from C# (solves a different problem)
Preventing blocking dialogs/message boxes/hanging GUI from non-interactive processes on Windows? (promising solution but C++-specific)
Prevent child process from creating visible windows? (solves a different problem)
Have you considered asking your development team to have a "no dialog" mode of the app for testing purposes? Perhaps if you stopped referring to them as (!!*&%) they would be more inclined to partner with you. ;) Afterall, you do work at the same company on the same product :)
In any case, without a dev-specific solution, consider having a another app (process or thread) that continually sleeps for a few seconds, wakes up and looks for a modal dialog in your application. You can use APIs such as FindWindow to identify when a modal dialog has popped up. (Use Spy++ to get the class name for windows created by MessageBox and CreateDialog APIs).
I'm writing WPF application
application targets all sort of windows and low performance computers
so I want to write launcher/splash screen for it which will be displayed before application loads
I'm not sure what language to use or what technology
I want it to be very fast and lightweight
can you suggest anything ?
Displaying a flash screen is as easy as popping up a dialog. If the dialog has the various resources such as bit maps already included then it is quite fast. However one issue that will determine this speed is how much other stuff is being initialized at application startup before the code is hit to display the dialog.
So one option would be to have a very simple application that does nothing more than display the flash screen and then start up the actual application. A simple Windows dialog application would do that. You would need to figure out how to synchronize the actual application finishing its initialization and the launching application stopping if you choose this route. There are several techniques for this and the most likely would be to use an interprocess mutex or perhaps just look for a file to be created.
For a point of sale I work with that is launched as part of turning on the terminal we ran into problems in which the application would start before some required system services such as database manager were up and running.
We have found that some environments require much more time than others so a registry variable makes it easy to tweak the delay in the field.
So as part of the application initialization what we did was that when the application starts up, it displays a dialog with a progress bar. The progress bar does a count up and we have a loop that does a one second sleep then increments the progress bar.
The number of seconds to wait is a registry setting for the application with a default value.
One problem we ran into was that when doing development and testing in a debugger, the default value was way too long for impatient programmers wanting to get started so we have condition compile so that if it is a debug compile, the delay is set to a couple of seconds. Otherwise the default is 10 seconds. However it can be changed with a change in the registry value.
See also this Stackoverflow about a launcher.
If you want something realy fast and lightweight, C would be nice.
If you dont want to learn C, you can also make a console application with .NET and C# it's fast too
Edit for comment: You can use a library like SDL wich is very fast and powerfull, and can draw images from a console application.
I find myself working with GUI code where the GUI program needs input focus and remain the topmost window, but whenever I'm debugging with VS stepping-through with F5/F10/F11 requires that VS has focus.
Is it possible to have VS intercept the F-keys whilst the debugee has focus? If VS doesn't have this functionality I imagine it should be possible to write a simple program or VS add-in that has a keyboard book and commands the debugger accordingly - has anyone developed such a program?
I'm working with a GUI test automation framework that sends mouse-clicks and other events by moving the cursor. When the debugee program is out of focus any click on its surface brings the main window forward but does not activate any controls, but the automation framework assumes that its focus of the application will never be interrupted. So if I set a breakpoint before a click that is meant to open the File menu then the click that is sent will only restore the debugee's focus and not open the File menu (if that makes sense).
I've done some searching but couldn't find anything immediately.
Why do you need to maintain focus? Have you specific hooks in the GotFocus/LostFocus?
I've had problems before with the Paint event being called as soon as F5 was hit causing the debugger to show again and therefore requiring another repaint. I got around these simply by arranging my windows so they didn't overlap. I'm pretty sure the LostFocus/GotFocus pair also don't fire when the windows are arranged this way too.
When my program is paused in Visual Studios 2010 during debugging, like from reaching a break point and me doing a manual step through, the program window becomes impossible to view.
It is a GUI window not a console window, which I run simultaneously with my program and am still able to view. The window seems to be open it's just that when I click its icon on the taskbar it doesn't come to the front of all the other windows. When I minimize all the windows in front of it, I see the outline of the window but it is either blacked out or showing the remnants of previously expanded windows.
I've noticed this with using Visual Studio's before (various versions of it), and after trying other IDE's that didn't have this behavior I notice it more. It would be really helpful to view the program's change's as I step through the program. Anyone know how I can do this?
I searched a long while and couldn't find a single reference to this matter.
The reason the window doesn't display is that the window paint message won't be processed if the main thread has been paused. Which other IDEs let you do this? I haven't come across any native code debuggers that do this on Windows.
If you are stepping through code that is run by the main thread, then the main thread can't simultaniously poll the message pump, which is needed for the GUI to work.
If you debug a different thread, the GUI will work while you are debugging.