Mouse trouble

[Brandon Kilgore]

At 12:34 PM 7/16/01 +0200, Ove Kaaven wrote:

>On Sun, 15 Jul 2001, Daniel Bingham wrote:
>
> > I just got the latest CVS and when I tried to run starcraft my mouse
> > won't move.  I have dxgrab turned on so as not to have my mouse going
> > off the screen when I try to move.  I am not very knowledgeable about
> > wine or programming, so I thought I'd tell someone who was.
>
>Known bug in the current CVS. Turn dxgrab off. If it's on, mouse events
>are lost. I'm working on it, but have not yet thought of a way to fix it;
>I need to run a procedure (GrabPointer) in the context of the thread that
>owns the window that gets the grab. My latest idea was to queue an APC to
>the owner of the window, but QueueUserAPC requires a thread handle, while
>GetWindowThreadProcessId only returns a thread ID.
>
>Does anyone else on wine-devel have any other ideas?

Is there any way you could create a linked list of thread IDs and Handles 
as they are created so they can be queried at a later point?  I don't know 
how feasible this is.  There's no way defined in the Win32 libraries to go 
from a thread ID to a handle.  Microsoft suggests asking the thread to 
DuplicateHandle().  Also, if you're running this procedure in the context 
of the thread that owns the window, shouldn't you have access to it's handle?

This is the excerpt I found from Microsoft:
---------------------------------------------------
The CreateThread() API is used to create threads. The API returns both a
thread handle and a thread identifier (ID). The thread handle has full
access rights to the thread object created. The thread ID uniquely
identifies the thread on the system level while the thread is running. The
ID can be recycled after the thread has been terminated. This relationship
is similar to that of the process handle and the process ID (PID).

There is no way to get the thread handle from the thread ID. While there is
an OpenProcess() API that takes a PID and returns the handle to the
process, there is no corresponding OpenThread() that takes a thread ID and
returns a thread handle.

The reason that the Win32 API does not make thread handles available this
way is that it can cause damage to an application. The APIs that take a
thread handle allow suspending/resuming threads, adjusting priority of a
thread relative to its process, reading/writing registers, limiting a
thread to a set of processors, terminating a thread, and so forth.
Performing any one of these operations on a thread without the knowledge of
the owning process is dangerous, and may cause the process to fail.

If you will need a thread handle, then you need to request it from the
thread creator or the thread itself. Both the creator or the thread will
have a handle to the thread and can give it to you using DuplicateHandle().
This requirement allows both applications to coordinate their actions.
---------------------------------------------------