I have a C++ software based on MFC (CDialog). When it starts it is always requesting for focus, mean it is blinking in the windows task bar.
The issue is that task bar is suppose to be set in out hide mode (because I have some other UI that are supposed to cover the full screen). But since this software always request focus, windows task bar never hide until I show and hide this piece of software...
I have other MFC softwares that do not have this behaviour but so far I cannot find out what could be the difference !
If someone had a idea that would be nice !
Thanks in advance.
Looks like I am doing some progress...
If I had ShowWindow(SW_SHOWNORMAL); just before the return of the OnInitDialog() function, then I don't get this behaviour anymore.
That is of course not perferct because I would like this application to be minimized and silent at startup, but when I try ShowWindow with other agrument I always get this flashing issue back...
Any other ideas are welcome ! Thanks.
Related
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 am working on an application for a customer and have hit a problem.
The application talks to the mobile phone and does a bunch of call handling. One of the things it does is to show an "answer call" button. Clicking this with the mouse works fine.
But the customer wants to have a keyboard shortcut for this, and that's a problem. I can get the focus if a window in the application has focus. But Windows focus steal prevention doesn't allow me to take focus if the user is in a different application.
Please don't discuss the pros and cons of focus stealing here. I know them already and have given them to my customer. Wrong or not, they still want to do this, and they are paying the bill, so they get to decide.
There are a number of workarounds for this, but they do not seem to work anymore. For example, I set HKEY_CURRENT_USER\Control Panel\Desktop\ForegroundFlashCount to 3 and ...\ForegroundLockTimeout to 0.
So what are my options? Is this impossible? Or do I have to build a keyboard hook application that virus checkers will hate?
This is a Qt/C++ application, but if you have C# example code that can do this, that is great as well.
I hope you can help.
I do not know how dated this is but you could try RegisterHotKey.
It allows you listen for keyboard events system wide and not just when your application has focus. You don't have to provide your window handle, if you leave that argument null the events are still posted to your thread.
I have this XP app (win32 C++) that I am just now testing under Windows7 (vista actually, but it does the same thing in windows 7).
I'm surprised that virtually the only issue I'm encountering is the following:
None of the scroll bars in a complex modelless dialog are functioning correctly. The main problem is the scroll thumb is not responding - just stays locked in position if you try and move it. Have had no issues going all the way back to win98, win2000, and winxp. Only in windows 7/Vista just now
But there is no commonality in the scrollbars in this dialog to explain it: One is in a plain richtext control created through a resource file. Another is in a richtext created through CreateWindow. And yet a third scrollbar is in a custom window class. None of them are working correctly (although you can make them scroll by right clicking and selected "Scroll Here".)
So I'm presuming maybe most encountered this a few years ago when porting to Window7/Vista for the first time, but I'm not finding anything in google now.
For modeless dialogs, you have to run IsDialogMessage in the main application GetMessage Loop, so messages for modeless dialogs are not subject to TranslateMessage and DispatchMessage. So I was doing that previously. However, Vista/Win7 doesn't like WM_MOUSEMOVE, and WM_LBUTTONDOWN and WM_LBUTTONUP to be bypassed like that for the dialog (i.e. they need to stay in the main App message loop). At least this was the problem in my case. I check for those message types now in the main message loop and that solved my problem. Can't explain it necessarily. Also couldn't explain why no one's encountered this previously (could be some idiosyncracy of my set up I guess). THanks for those who looked into this.
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 have tried to make the fullscreen feature of a SDI application with splitter windows by following the forum link. However, my status bar, system menu as well as the title bar of the application have disappeared. Do you have any suggestions on any easy ways of getting these back (or if I have to use different method of making the application maximized during startup instead of fullscreen)? Thanks in advance.
I got rid of any manipulations on the cs structure in the PreCreateWindow handler and used a ShowWindow(SW_MAXIMIZE) function call in the OnCreate function implementation of my MainFrame function, and it works quite well.
It sounds like you just want the window to be maximized. Take a look at the SetWindowPlacement function or ShowWindow.