OnMouseWheel event with MFC - visual-studio-2010

I am having some problems with the ON_WM_MOUSEWHEEL event and MFC. The function handling the event does get called, but not when scrolling, just when "pinching" the touchpad. Is it supposed to behave like this?
I am using Visual Studio 2010 and Windows 7.

I've noticed that some touchpad drivers implement scrolling using the WM_VSCROLL message, however since the java AWT's mouseWheelListener is working, my recommendation would be:
Open Spy++ and verify whether or not WM_MOUSEWHEEL messages are being posted.
If messages are not being posted the control might not have focus.
If messages are being posted, it might be a problem with the way the control is attempting to receive the message. In this case, showing us the message map might help.

Take a look at the WM_TOUCH message.

Related

Preventing WM_SETCURSOR and WM_NCHITTEST messages from being generated

I'm making an application that hooks itself in to a target application and, when activated by the user, prevents all keyboard and mouse window messages from reaching the target application's window proc. My application does this by translating the incoming input messages, such as WM_MOUSEMOVE, to WM_NULL, so that the window proc is unaware input happened.
The problem is that Windows also automatically sends WM_SETCURSOR and WM_NCHITTEST to the window proc (e.g. when the application calls PeekMessage) when mouse input occurs. These messages aren't posted to the window's message queue, so I can't change them to WM_NULL.
I initially worked around this by subclassing the window proc and simply ignoring WM_SETCURSOR and WM_NCHITTEST there, but subclassing seems to have compatibility issues with some of the applications I'm hooked in to.
My question is: How do I prevent WM_SETCURSOR and WM_NCHITTEST from being generated in the first place OR how do I prevent them from reaching the application's window proc.
Some Ideas to Try
I just finished implementing a global/system wide CallWndRetProc with a WH_CALLWNDPROCRET Windows Hook (like it describes in the past post of the link below).
http://help.lockergnome.com/windows2/Igor-SetCursor-SetWindowsHookEx--ftopict285504.html
Using that in combination with hiding all the system cursors using SetSystemCursor has effectively hidden the cursor for most applications.
If you wanted to continue hacking at this target application, you could try using API Monitor to diagnosis what is going on: http://www.rohitab.com/apimonitor
The guy at rohitab hints at releasing his source code eventually; his site seems to have some of the better forums about Hooking, Subclassing, Injecting, etc.
It sounds like you successfully used SetWindowLongPtr(), but there are a few different ways to get into the address space of the program you are working on...
Have you tried SetCapture()?
Other Links
Here are a few other links that may be useful:
http://support.microsoft.com/kb/31747
http://msdn.microsoft.com/en-us/library/windows/desktop/ms646262(v=vs.85).aspx
http://msdn.microsoft.com/en-us/library/windows/desktop/ms633569%28v=vs.85%29.aspx#winproc_subclassing
http://msdn.microsoft.com/en-us/library/windows/desktop/ms648395(v=vs.85).aspx
Hope that helps. Good luck.

WM_TOUCH is not immediately sent with touch down event

I am working with a touch screen and using Windows 7 built in drivers (as it never prompted me to install any). it works fine, except for one small issue. When I touch the screen, it will not send the WM_LBUTTONDOWN until I move my finger off the screen. It appears to do this to determine if I intend to hold down to emulate WM_RBUTTONDOWN or not. (Also, I tried to disable the hold down emulate gesture, but it never disables in practice.)
So I thought I would just receive the WM_TOUCH messages. And I found that WM_TOUCH (0x240) is also not sent to my window until I move my finger off the screen. I sort of thought that defeats the purpose of WM_TOUCH altogether.
Both before and after registering to receive WM_TOUCH messages, I received three messages immediately upon touching the screen:
1. Send: 0x02CC (undocumented tablet messages)
2. Post: 0x011B (undocumented)
3. Send: 0x011A (WM_GESTURENOTIFY)
0x011A is WM_GESTURENOTIFY, which my code is to respond to (perhaps I am not responding correctly?). I reply with a standard response (using sample code from MS) to receive full notifications.
Another thing, I began getting WM_TOUCH when I register for touch messages, but I continue to get the WM_GESTURENOTIFY message as well. According to the MS documentation, once I register to get WM_TOUCH, I no longer get gesture messages.
If anyone can tell me how to get WM_TOUCH messages immediately (e.g. when I am getting the WM_GESTURENOTIFY messages), and not after I let my finger up off the touch scree, I would appreciate it much.
Check out this tutorial on touch events:
http://msdn.microsoft.com/en-us/gg464991
What you want to use is the RegisterTouchWindow function, as such:
RegisterTouchWindow(handle, 0);
Windows will now send WM_TOUCH messages instead of WM_GESTURE messages to your window. Keep in mind that you will have to compile against Windows SDK version 7.0 or newer for this to work.
I almost got the same issue and solved it by using :
RegisterTouchWindow( hWnd, TWF_WANTPALM );

Qt::X11BypassWindowManagerHint functionality on Windows

I'm currently developing a cross-plataform virtual keyboard. In linux i was able to do whatever i want, but in Windows i'm having problems to prevent the widget to obtain the keyboard focus.
In linux, using the window flag
Qt::X11BypassWindowManagerHint
the widget never gets the keyboard input, but of course, that flag does not work on Windows
Is there something equivalent to that flag or some method i can use instead?
any ideas would be appreciated
thanks in advance
I posted an answer to a similar question over in Make a floating QDockWidget unfocusable. On Win32 you don't really have the choice of bypassing the window manager completely, but you should be able to get most of the behavior you want by intercepting nativeEvent to handle WM_MOUSEACTIVATE.
I would try to ignore the event. I believe you need to ignore FocusIn on the main application window - not sure about the actual event, you might need to prototype it. You can do ignore events by either installing an event filter or manually re-implementing one of the event methods (possibly event itself). I don't know which is the preferred way though but I'd attempt the event filter first for this task: http://doc.trolltech.com/4.6/qobject.html#eventFilter
I've never tried to capture the keyboard focus event, but I have been able to successfully ignore escape keys in a QDialog to prevent users from accidentally closing the window. I believe it should be possible.

WM_POWERBROADCAST handler for CMainDlg in ATL app not invoked

I have an ATL app where I want to handle WM_POWERBROADCAST. I have a CMainDlg (CAxDialogImpl) in whose MSG_MAP I defined the handler.
BEGIN_MSG_MAP(CMainDlg)
...
MESSAGE_HANDLER(WM_POWERBROADCAST, OnPowerChange)
...
END_MSG_MAP()
However, the handler isn't invoked when I do things that should invoke it, for instance change power settings or put the machine to sleep.
Any ideas about what might be going on, and how to fix this? Does CMainDlg not get notified of power events, for some reason?
I suspect your dialog not being a top level window (WS_POPUP styled).
Just tested with a WTL AppWizard non modal dialog app that WM_POWERBROADCAST is received (without any registration) on AC plugged/unplugged.
Did you register to receive the power events?
To add to answers above, you might want to use Spy++ tool to make sure the messages of interest are posted to your application in first place. You will also see which windows they are posted to, and if it is your window where you are waiting for this message.

Suppressing popups in Windows

Is there an easy way to tell Windows not to display popups on a headless server machine?
Currently occasional application popups are causing my app to freeze because no one is available to press 'Okay' on the console. Just logging to the eventlog would be more than sufficient.
Depending on precisely what popups need to be handled, there are a couple of approaches.
For hard error popup handling, HOWTO: How To Change Hard Error Popup Handling in Windows NT
Creating an application to suppress messages. Microsoft has some documentation (from the XP Embedded documentation, but this does not require XP Embedded): Creating a Win32 Service This allows for considerable customization in the handling of the messages, logging, and replies (i.e. depressing the button you want).
It all depends on the kind of popup, from system's message box to custom dialog. So I don't think there is a generic solution to this.
Should I have the problem, I would use a macro language, like AutoHotkey (or AutoIt), to detect the activation of the popup and automate the click on the discard button.
[EDIT] Found a ready to use AHK popup blocker: New window (popup) blocker
Perhaps usable as is, or as a starting point.

Resources