I'm trying to track down the buttonup issue for Foxpro, and I've found
an inconsistency, but I can't track it down.
I started with GetCursorPos. It assigns PosX to pt->x, and PosY to
pt->y, then calls X11drv.GetCursorPos, and assigns the current mouse
coords to pt->x and pt->y.
The problem is when the button is clicked, PosX and PosY retain the
original values forever:
A second or so after the left button is clicked:
*Input.c current GetCursorPos (490,172) && (490,172)
PosX,PosY && pt->X,pt->y
*Button1Mask / state 256 / 16 (button is now up)
*trace:cursor:X11DRV_GetCursorPos pointer at (489,186)
(Where X says the pointer is)
*-userdrivercall complete- (X11) Now: (490, 172)- 489,186-
PosX,PosY && pt->X,pt->y
(* my traces are just printf's)
Even though the values are updated, they never get reassigned to PosX
and PosY. I'm not sure WHERE that's supposed to happen, nor have I
been able to figure out where GetCursorPos is called from. Is it
possible that the values, and GetCursorPos are dealt with INTERNAL to MS
FoxPro?
I also am finding that the Wine server is returning Status Pending, then
Status Timeout in WaitforMultipleObjectsEX in synchro.c. This happens a
couple times when FoxPro starts up, but is eventually 'broken' out of.
The Status_Pending triggers a call to wait_reply() in
WaitforMultipleObjectsEx which does:
ret = read( NtCurrentTeb()->wait_fd[0], &reply, sizeof(reply) );
GetCursorPos is called about 180 times before ret is set.
I can't seem to find any reference to NTCurrentTeb in Wine (grep -nr),
even though I found mention of it in the archive. Seems like an
internal OS call.
I don't know what's calling GetCursorPos, I don't know where pt->x gets
assigned to PosX (but that's just a side effect, the mouse moves, it's
the button that's stuck), and I don't know why wait_reply is getting a
STATUS_TIMEOUT.
Any ideas for me?
Thanks,
Rick