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