We have a kiosk system running on Win7 with application written using VS2010 C++. As with kiosk systems, the system is locked down so that the user cannot access the windows system itself, but must do all work using our application.
Unfortunately, we have had one issue so far where a windows system-level dialog has popped up requiring a response. It popped up behind the GUI of our application, so that the user didn't even know it was there, and since it was modal, it blocked further use of the system.
These dialog was the well-known "system needs to be restored" dialog. Since this is a kiosk system, we are wanting to find a way to handle these types of situations in an automated fashion.
I have looked into setting a low level hook using SetWinEventHook() to capture EVENT_SYSTEM_ALERT events. The first problem of course is that I am not sure how to test this, since these events are not common. The second problem is that I am not sure how to handle the information, since there could be a number of different system alert events that pop up modal windows, and so automating a response might get us into more trouble than we might foresee.
My real question here is, if you were in this exact situation, what would be your line of attack. I am concerned I may be going about this the wrong way by trying to capture alerts and somehow automate a response to the resulting system alert window.
Any clues as to a useful direction here would be much appreciated.
Related
I'm writing a keylogger/mouse tracker for use in an opensource input heatmapping application basically identical to Razer's newest heatmapping software, but for use with any hardware/OS (using Qt's amazing cross platform SDK). As you would imagine, this involves intercepting keyboard and mouse messages from the kernal when the application is not the main process.
For Windows I was drawn to GetAsyncKeyState, but there's a note on the return value from MSDN about this function returning zero if "the foreground thread belongs to another process and the desktop does not allow the hook or the journal record."
Barging ahead regardless, I wrote a method for getting the keyboard state (that triggers every set interval of time via Qt's QTimer methods) and it just worked:
//The following executes every 100th of a second:
for (int i = 0; i < 256; ++i)
{
keyboardArray[i] = GetAsyncKeyState(i);
}
As I watch this array in the debugger, I can see the values in the array change as I type even when the application is not the main process. So, for my computer at least this function works at monitoring key states when the main thread is not focused on my application.
My question is: In what instances does Windows not allow hooks or the journal record? In other words, are there some versions of Windows and/or privileges a user could have/not have where this method could fail? I don't really have access to a bunch of different machines to test this on.
My specs are Windows 7 Home Premium 64 bit, Intel i7 930 (2.8 GHz, quad core hyper threaded), 12 GB DDR3 1333 MHz memory, 2x Nvidia 460 if any of that helps.
Best Regards,
Weikardzaena
EDIT:
Hans Passant gave me an example of situations where this type of implementation would fail: mainly applications on Windows that include User Interface Privilege Isolation (UIPI). Basically if an application is really important to the operating system (like a command prompt) then this type of message intercept will not work. I even tested it and it's true: my application stops updating the keyboard array when a command prompt is the main thread.
This and what LoPiTaL said suggests that only specific applications will not allow this type of intercept to occur. I'm mainly aiming this application toward gamers who (like myself) would like to see key presses and mouse clicks for their gameplay, so maybe I don't care about this issue as much, but if I want to expand this to general use (including people who use CMD a lot) then it seems like there's actually no way to intercept key messages for those types of elevated applications.
Is that true, or can methods like SetWindowsHookEx still intercept messages to UIPI applications? I was trying to avoid implementing hooks directly because that might be viewed as a virus on people's home machines, and capturing and re-emitting every input message just slows down everything, which in gaming is pretty big deal.
I am running Mozilla Firefox on Windows 7 and would like to be able to send simple commands (New Tab, Minimize, Close Tab) to it from a C++ program.
The usual question of inter-process communication, when both processes are a part of the same user program, seems to be answered by Boost.Interprocess.
But what about actually controlling the GUI window of an entirely independent application (Mozilla)?
You can use Spy++ to debug what messages each action will produce, then replicate those messages in your program.
You can use Ranorex http://www.ranorex.com, Quick Test Pro http://www8.hp.com/us/en/software-solutions/unified-functional-testing-automation/index.html#.UpvC8OJO7tw
Will give you this ability
The general answer to controlling any Windows program through its user interface is by sending it Windows messages. There are also some rather specific Windows APIs that allow you to send specific kinds of inputs directly to the keyboard, mouse or other input device.
Assuming simple requirements, you should be able to control Firefox by sending it some combination of the messages WM_[SYS]KEY[DOWN|UP], WM_[L|R]BUTTON[DOWN|UP] or similar. You may also need to use FindWindow and other things to find where to send messages. And liberal use of Spy++ to figure out what to send and where to.
Actually, what I would do is start with AutoHotKey. It can do all this stuff and then some, and it has a massive community. It's GPL so you can find out how it does stuff and there are people there to ask for help.
I'm implementing a touch interface for Windows in Win32 (C++). I would like to find out the current double-tap (not double-click) speed that Windows is set to. I know Windows is set to accept double-taps as various messages (depending on whether you're using gestures or not), but I'm looking at doing something a bit more advanced. I'm thus handling WM_TOUCH messages. I'm hoping there's a better (i.e. future-proof) way than rummaging through the registry to find that setting. MSDN wasn't helpful.
Since there doesn't seem to be a specific double-touch notification, I suspect the application is expected to decided for itself if a WM_TOUCH is part of a double tap. The most common way to do that is probably to check the timing between touches. By default, I'd imagine that most apps use the mouse double-click setting as the default.
GetDoubleClickTime
In a c++ program run on Win7, is there a way to fake a mouse movement or something like that, just to keep the screen saver from starting and the system from going to sleep? I'm looking for the minimal approach and I prefer not to use .NET.
Thanks,
-nuun
Don't mess with the screensaver settings, use SetThreadExecutionState. This is the API for informing windows on the fact that your application is active:
Enables an application to inform the
system that it is in use, thereby
preventing the system from entering
sleep or turning off the display while
the application is running.
, and
Multimedia applications, such as video
players and presentation applications,
must use ES_DISPLAY_REQUIRED when they
display video for long periods of time
without user input
That's not a bad idea, any decent media player does it... Look for SystemParametersInfo(SPI_SETSCREENSAVEACTIVE ...) function in Win32 api, it should do the trick.
Before Windows starts screen-saver, it sends SC_SCREENSAVE notification in WM_SYSCOMMAND message to applications. If application wants to prevent screen-saver from starting, it should set "handled" flag to true and return zero during message processing. There is also SC_MONITORPOWER to prevent display from going to low power state.
https://learn.microsoft.com/en-us/windows/desktop/menurc/wm-syscommand
Background: I'm currently debugging an application written over a custom-built GUI framework in C++. I've managed to pin down most bugs, but the bugs I'm having the most trouble with tend to have a common theme.
All of them seem to be to do with the screen refreshing, redrawing or updating to match provided data. This is a pain to debug, because I can't break on every refresh, and most of this stuff is time-sensitive, so breakpoints occasionally "fix" the bug.
Q: Does anyone have any tips for debugging Windows-based GUIs, especially regarding the refreshing of individual components?
I agree with dual monitors or even remote debugging to reduce interfering with the messages.
I also highly recommend Spy utilities. These let you see what messages are being sent in the system. One such program is Winspector.
http://www.windows-spy.com/
This may not help, but I've found using dual monitors useful in this scenario. I have the debugger on one screen and the application on another. I can then step thru the code and see the application refreshing or doing whatever it is on the other screen.
There is still issues with focus doing this way, but at least I can see when it repaints.
Logging is pretty much the only answer. Without knowing your framework I can't give an exact answer but basically open a file and append messages in the various procedures of interest. Finally close it.
In the message include the values of the variable that you are interested in.
Also using the window Message Box is useful to see if you are in the correct branch or procedure. This has minimal effect on over all flow.
Finally try downloading any of the express version of .NET and use Winforms to try to make test of particularly problematical areas. While Winform is it own framework there is a high degree of correspondence between it's control and the ones provided by Windows.
I maintain a simulation of the Project Mercury Capsule as an add-on for the Orbiter Space Simulator. It is written in C++ and has to use Win32 directly for some of the panels and dialogs. There were times I fired up VB6 (VB.NET later) to work out some complex interaction and then translated it over to it's Win32 equivalent in C++.
However this is a last resort.
Having a dual screen really help when debugging refresh/redraw problem for Windows controls and UI.
Having the application on the second screen will not have the debugger generate "invalidate" on the main UI screens when it breaks for a debugging breakpoint.
If you cannot have a second screen, try to have both application side-by-side so that the application and the debugger will not interfere.