I'm receiving a windows message with code 1092 (0x444) and I don't know what it is. It's higher than WM_USER but I searched our code base and found no reference so I don't think it's one of ours... does Windows use custom messages above 0x400 and if so how can I look this up?
From the documentanion of WM_USER:
Message numbers in the second range
(WM_USER through 0x7FFF) can be
defined and used by an application to
send messages within a private window
class. These values cannot be used to
define messages that are meaningful
throughout an application, because
some predefined window classes already
define values in this range. For
example, predefined control classes
such as BUTTON, EDIT, LISTBOX, and
COMBOBOX may use these values.
Messages in this range should not be
sent to other applications unless the
applications have been designed to
exchange messages and to attach the
same meaning to the message numbers.
So, that message can be anything.
A quick look in the MFC source code, for example, reveals these definitions
// COMMCTRL.H
#define TB_ADDBUTTONSW (WM_USER + 68)
// RICHEDIT.H
#define EM_SETCHARFORMAT (WM_USER + 68)
I searched for 68 because 0x444 = 0x400 + 0x44 = WM_USER + 68
Any application can use messages above WM_USER or WM_APP. Windows itself even uses messages above WM_USER. Because any application can broadcast these message values (and some do, because they're written by idiots), you should always use registered messages for private comms.
You could use Spy++ to try and track these messages down, but you can't guarantee ever stopping them all, so it's best to avoid them by using RegisterWindowMessage.
You could search around in the Windows headers for strings like 0x444, 0x0444, 0x00000444, etc.
It might also be a rogue application sending around messages that it shouldn't.
Related
I need to hook globally mouse clicks and block last click if delay between two clicks is less than was set.
I wrote it for windows using WM_MOUSE_LL hook.
I was unable to find any solution for me. Is it even possible to globally block mouse click in X11 ?
Windows full code
As far as I know the standard X11 protocol doesn't allow this. The XInput 2.0 extension might, but I doubt it.. while Windows assumes a single event queue that every program listens to, so that a program can intercept an event and prevent it from being sent down the queue to other listeners, every X11 client has its own independent queue and all clients that register interest in an event receive an independent copy of it in their queue. This means that under normal circumstances it's impossible for an errant program to block other programs from running; but it also means that, for those times when a client must block other clients, it must do a server grab to prevent the server from processing events for any other client.
Which means you can either
use an X server proxy (won't be hard, but will be pretty slower)
or
do it on the input device level. /dev/input/event<n> give you the input events. You can read off the keypresses there and decide if they should propagate further be consumed. Unfortunately there's no real documentation for this, but the header file linux/include/input.h is quite self explanatory.
My application's user interface consists of two windows: the console (handled by ncurses) and an X11 window for graphics. I would like to handle key events in a centralized way. That is, no matter which of the two windows is active, the same event loop should handle all the key events. I already have an event loop for X11 events. All that remains to be done is to forward all the console events to the X11 window.
The main building block to achieve this forwarding is found here. The only other thing I need is to be able to translate from the value returned by getch() to X11 keycode. After about four hours of searching the web, I found this code, which is part of qemu. However, when I compare the mapping it provides with the output of xev, the two do not match. For example, for the Home key, xev gives 110, while the mentioned mapping gives 71 | 0x0100, which is 327. Are these two different kinds of keycodes? What am I missing?
Hmm, mixing application frameworks is, almost by definition, difficult.
I think the best way to achieve what you want is to have two separate processes or threads, one for the console and the other for the X11 application. In each you would have the relevant event loop handler. To join them together use an IPC channel, either a pipe or socket. You should be able to make the socket/pipe an input to the X11 event loop handler with its own callback. You can have a select() on the console side waiting on the socket or STDIN; this allows you to call getch() when there's a keypress ready or read from the socket when the X11 has sent something through the socket. If you used something like ZeroMQ in place of the socket, even better.
So, what would you send through the socket? You would have to define your own event structure to pass between the console and the X11 application. Each side would populate and dispatch one of these when it needs to send something to the other. The types of event you'd need to describe would include would be things like quit, keypress (+ keypress data), etc.
Most likely you'd arrange the X11 end so that the socket reading callback read the structure from the socket, interpreted it and decided what callback should then be called directly. If your key presses are only for selecting menu entries, buttons, etc then this might be a not-too-bad (but not brilliant) way of avoiding the mapping problem.
This does mean having two event loop handlers, a socket and two processes/threads. But it does avoid blending the two into a single thing. It also means your console could be on a completely different machine! If you had used zeromq you could easily have multiple consoles connected to the X11 application in a PUSH/PULL configuration; perhaps absurd, but possible.
I have a message-only window (ATL::CWindowImpl) that registers itself for raw input using the RIDEV_INPUTSINK flag, meaning it gets all input regardless of whether the window is the foreground window. This works great when there's only one instance of that window.
However, when I create more than 1 instance of my window, only one receives the WM_INPUT messages (I'm currently creating two, and only the second one to be created gets the messages).
RegisterRawInputDevices (using RIDEV_INPUTSINK | RIDEV_NOLEGACY) is succeeding during the creation of both windows. Also, the window not receiving raw input is still receiving other messages, so it's not a problem with the window itself...
If it's relevant, I'm using the VC11 beta, and windows are created and dispatching messages on different threads (using std::thread).
Is this an API limitation (i.e. you are limited to one input sink per process)? Or is there a way to get this working?
Thanks in advance.
EDIT:
Right now my current workaround is to just have one window and for it to pass on the input messages to the other windows, however this is a mess, and won't work in the case I want it to work in (where I have my app loading plugins which may want raw input, I don't want them to have to register with my app unless I really have to do it that way...).
From MSDN (here and here) the whole API for Raw Input talks always about application and not about window... which means that an application registering for raw input will be trated by the OS as one entitiy... which you indirectly proved by registering a second receiving winow - the first one just stopped receiving because the OS delivers raw input to the application (represented by exactly onw window as the sink).
We have a very large, complex MFC application.
For some reason a particular mode for running our application is generating WM_SIZE messages to the window. It should not be happening and is killing performance.
I can see the message getting handled. How can I find what or where in the code, is generating the window message?
Note: it tends to happen when we have a performance monitoring tool hooked into the application. So it might be the third party tool doing it.
But it only happens in this one particular mode of operation so it might be some sort of strange interaction.
You could see message map to specify for which all windows onSize has been mapped.
as an 'not elegant' alternative, you could trape WM_ONSIZE in PreTranslateMessage and see windows handle using hwnd member of pMsg structure being passed in PreTranslateMessage.
How would it help to know who sends the message? I would rather focus on a solution, such as delay processing of the message (assuming this processing is responsible for the perf hit) when an avalanche of such messages is detected.
e.g. If you receive too many messages within x milliseconds, you may decide to start a timer and process only the last message receives when the timer elapses. This way, you process max one message per x milli-seconds instead of each one.
Is there a way to define and send custom message types in Win32, to be caught by your Main message handler? For example, my main message handler captures messages such as WM_PAINT, WM_RESIZE, WM_LBUTTONDOWN etc. Can I create my own WM_DOSOMETHING? If so, how would I send this message?
Ah, I actually just discovered this was asked before here, however, it doesn't answer how I would actually send this message.
Woah, let's just stop and think here...
First of all, Windows itself sends messages in the WM_USER+n range, that's why WM_APP was invented (I found this out the hard way). But it gets worse... there's nothing to stop badly behaved applications broadcasting WM_USER+n or WM_APP+n messages, and because human beings stole the crystal of infinite stupidity from the Gods, this does indeed happen in the real world.
So, repeat after me, the only safe message is one I define myself and can only see myself. Use RegisterWindowMessage. And even then, be untrusting. When I need a string to define a RegisterWindowMessage, I use GUIDGEN to create the string and put a human-readable app-specific prefix on the resulting gobbledygook to help me differentiate multiple messages in the code.
Bet on the stupidity of your fellow humans - it's always a winning bet.
If you want authoritative background on this whole topic, see here. No that's not my website, it's Joe Newcomer's.
Yes. Just declare a constant in the WM_USER range e.g.
#define WM_RETICULATE_SPLINES (WM_USER + 0x0001)
You can also register a message by name using the RegisterWindowMessage API.
You can then send these messages using SendMessage, PostMessage or any of their variants.
If you created the window class, you can use the WM_USER range (or WM_APP)
If it is not your class, you can use WM_APP
If you want to broadcast the message to every top level window, register your own global message with RegisterWindowMessage