We have an application that downloads some files in the background. Our application pops up when an Internet connection is made, and after prompting the user to accept the downloads, we'd like to switch back to the home screen while we do our stuff.
We can't work out how to do to this. We can emulate pressing "back" a few times, which sometimes works, but where you end up depends on what the user was doing when the Internet connection happened.
So, can someone provide pointers to how to do this?
Thanks.
Paul.
Can you try setting the today screen as the foreground window?
HWND hWnd = FindWindow(_T("DesktopExplorerWindow"), _T("Desktop"));
SetForegroundWindow(hWnd);
Why don't you simply hide your app?
Using a Notification shell object instead of popping up a full screen window might be a better alternative. Details here.
Related
So I have a MFC application which flick when we do some action.
So I figured I would set SetRedraw(false) and set it to true at the end of the function.
The application doesn't refresh anymore but if I click on it while SetRedraw(false), my cursor is not catched by my application, it goes throught it and set focus on the application below.
Anyone has some kind of idea how I could fix that.
I ended up using CWnd::LockWindowUpdate instead after some research.
It freezes the update but doesn't act if the window was transparent.
I'm trying to use SendMessage to post mouse clicks to a background window (Chrome), which works fine, but brings the window to front after every click. Is there any way to avoid that?
Before anyone says this is a duplicate question, please make sure that the other topic actually mentions not activating the target window, because I couldn't find any.
Update: aha, hiding the window does the trick, almost. It receives simulated mouse/keyboard events as intended, and doesn't show up on screen. However, I can just barely use my own mouse to navigate around the computer, and keyboard input is completely disrupted.
So my question is, how does sending messages to a window affect other applications? Since I'm not actually simulating mouse/keyboard events, shouldn't the other windows be completely oblivious to this?
Is it possibly related to the window calling SetCapture when it receives WM_LBUTTONDOWN? And how would I avoid that, other than hooking the API call (which would be very, very ugly for such a small task)?
The default handling provided by the system (via DefWindowProc) causes windows to come to the front (when clicked on) as a response to the WM_MOUSEACTIVATE message, not WM_LBUTTONDOWN.
The fact that Chrome comes to the front in response to WM_LBUTTONDOWN suggests that it's something Chrome is specifically doing, rather than default system behaviour that you might be able to prevent in some way.
The source code to Chrome is available; I suggest you have a look at it and see if it is indeed something Chrome is doing itself. If so, the only practical way you would be able to prevent it (short of compiling your own version of Chrome) is to inject code into Chrome's process and sub-class its main window procedure.
I know this type of thing is looked negatively upon but I write software for people with disabilities and sometimes good gui practices don't make sense. In this case, the user interacts with a assistive interface and under certain conditions, my control app needs to prompt the user with a question. My background process creates a dialog (I'm using wxwidgets wxDialog class) and calls Show(). The dialog box appears but it does not have focus (the application that the user was previously using keeps it). Since my users can't use mice, they can't simply click on the window. I've tried calling show and then followed by SetFocus(HWND) but that doesn't do it. What's the problem? Is this even possible? Window7. I'm thinking that it might have something to do with it being a dialog and not a full window (wxFrame). Any help is greatly appreciated.
Try using SetWindowPos(hWnd, HWND_TOPMOST, 0, 0, 0, 0, SWP_NOSIZE|SWP_NOMOVE)
Unfortunately, not only is it 'looked negatively upon', but it is not possible. There's no getting around this; ask yourself what would happen if every application could do this? Obviously, if you can put your dialog on top of the other application, it can do exactly the same back to you.
http://blogs.msdn.com/b/oldnewthing/archive/2010/11/25/10096329.aspx
The only think I can think of would be for you to put a notification icon in the system tray, and then have it display a notification balloon.
I had to do something like this before. Simply calling functions like SetForegroundWindow or SetWindowPos didn't do the trick.
I ended up using this ForceForegroundWindow function (1st one) and it works pretty well.
I know this is Delphi code, but the API is the same and Delphi is a pretty simple language.
I need to create an application which do the following:
At the beginning we have notepad window open with a lot of text in it.
Our application must scroll through this file and take notepad window screenshot after each scroll action.
I've tried to achieve this using SBM_GETRANGE, SBM_GETRANGE, SBM_SETPOS but it does not work for me.
Please note that emulating keyboard events (e.g. PageDown, PageUp) is not an option for me because this application should also work with other applications which may not support keyboard shortcuts for manipulating scrolls.
Thanks.
Don't try to manipulate the scrollbar directly - instead SetFocus() to the text window, then send Page Down messages. If there are applications where you must manipulate the scrollbar, you should get its window handle and send the messages there.
When I attempt to use SetCursorPos at the Windows Vista/7 login screen, true is returned which at first made me think it was working. However, when I call GetCursorPos it gives me:
-858993460,-858993460
Any thoughts why? Is this a "security feature" or am I using it incorrectly? The code works fine on non-login (i.e. normal) desktop.
From the MSDN:
The input desktop must be the current desktop when you call GetCursorPos. Call OpenInputDesktop to determine whether the current desktop is the input desktop. If it is not, call SetThreadDesktop with the HDESK returned by OpenInputDesktop to switch to that desktop.
This page (where I got the above quote from) which asks the question "GetCursorPos not working if desktop is locked", has the following information:
You can't get this information while the desktop is locked. While the
desktop is locked, the security subsystem takes over, and your desktop is
off limits.
At that point, you would have to hook into the O/S (people have done it
by replacing GINA.dll, but you can't do this in managed code, and on top of
that, you can't do it in Vista, as it has a different model).
While the desktop is locked, you are going to have to do without cursor
information if you are using managed code.
On the login screen and on the security window you cannot send mouse or keyboard events. This is a security measure for Windows in order to prevent unauthorized access from different programs.
Alternative solution: It is possible (but very tricky) to use mouse_event (which does work at login screen) instead of SetCursorPos. I don't have time to post code now, but if asked I may update this answer...