Hi,
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. If I have something set up wrong I can't find it and don't find any documentation to address it either. Any help would be much appreciated. Please email me directly because I get the digest and tend to ignore it. Thanks.
Daniel Bingham db78@att.net
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?
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. ---------------------------------------------------
-
Brandon Kilgore -
Daniel Bingham -
Ove Kaaven