Posted to provide an update on a pointer that made contact over the client area of a window or on a hovering uncaptured pointer over the client area of a window. While the pointer is hovering, the message targets whichever window the pointer happens to be over. While the pointer is in contact with the surface, the pointer is implicitly captured to the window over which the pointer made contact and that window continues to receive input for the pointer until it breaks contact.
Basically there are various trouble with the Pointer Device as implemented in modern Windows applications. Normal Windows apps including LabVIEW should not be concerned about this interface at all. Windows will then translate the messages to WM_MOUSEDOWN and friends messages instead, which LabVIEW and most other applications really will use. But those messages may be sent directly to the target window over which the event occurred and that is not the callback that is installed by the Windows message queue library.
Windows message hooks come in various flavors, one of them is hooking a specific window procedure, another one is hooking the main message loop procedure. Typically device messages such as from the pointer device get sent to the main message loop and may then be sent down the windows chanin to each individual window until one of them tells Windows that it handled it and doesn't want it sent to other windows in the chain. Other messages such as mouse events are only sent to the window over which the actual event occurred and if that window didn't handle it to its parent and so on.
All this makes windows message hooking a very complicated and non-user friendly business. For you it is important to know that the Windows message queue library does hook the main windows message loop in LabVIEW and not an individual windows procedure. Which messages get sent to which type of message hook, in which order and such, is tricky to know, kind of undocumented and can even change between Windows versions, which is why it is not such a good idea to try to process such low level events and even less to try to hook into them.
One other interesting tidbit on the MSDN page about these event messages is that they work in real DPI resolution and therefore only match with applications which are DPI aware. LabVIEW as a classic app is not DPI aware and doesn't announce to Windows through a manifest that it is, so Windows will virtualize the DPI settings for LabVIEW in its various high level messages such as WM_MOUSE.... etc, but that virtualization is not applied to WM_POINTER.... messages and therefore the coordinates may seem off from the ones LabVIEW works with.
