myoung@b11.ingr.com (Mark Young) (04/25/89)
What is the proper behavior for the cursor when a server changes screens?
We have a server implementation that can be traced through the following
sequence of events:
We call NewCurrentScreen from the ddx layer when we detect that the user
wishes us to change screens We are passing a legitimate cursor location
to NewCurrentScreen, but this cursor location always seems to get ignored.
after tracking the problem, it appeared to be due to the fact that the
sprite.hot.x and sprite.hot.y were set to -1 in ConfineCursorToWindow
when the screen changes. In ConfineCursorToWindow, a call is made to
the function (* pScreen->SetCursorPosition)(pScreen, x, y, generateEvents);
which seems to set the correct cursor position. It, however, is followed
by a call to CheckPhysLimits which, after determining that the coordinate
specified by sprite.hot.{x,y} is out of bounds (since we it was set to
(-1,-1) in ConfineCursorToWindow, sets the sprite coordinate to (0,0) and
set the cursor position to the same.
We support two logical screens on the same physical screen (this is a useful
side effect of the proprietary window system; one has four planes and the
other has one plane). of course, because of this problem, when the user
switches between screens, the hardware cursor always warps to (0,0).
Any and all input would be greatly appreciated.
...m (tired of cursor chasing) young
--
myoung@ingr.com | mark allan young | where
uunet!ingr!myoung | intergraph corp, cr1105 | do I
| one madison industrial pk | put the
"Say, I thought everyone had heard | huntsville, al 35807 | usual
of Intergraph?" | (205) 772-6094 | disclaimerrws@EXPO.LCS.MIT.EDU (04/26/89)
What is the proper behavior for the cursor when a server changes screens? Something proper, of course. :-) What you describe is a known bug in the R3 server. There is no blessed fix at this point (and probably won't be until R4, given how much server sources have changed since R3 already). FYI, here's a suggested fix we received; it will have to be up to you to decide if it's the right one: CheckMotion is called when a motion event is generated. With few exceptions, the x and y values will be different from the sprite.hot values. It seems that the easiest way to fix this is for CheckMotion to call XYToWindow unconditionally and eliminate the setting of sprite.hot in ConfineCursorToWindow. SAMPLE FIX: (the suggestion is to delete the indicated lines) 294a295,296 > sprite.hot.x = -1; /* cause new sprite win computation */ > sprite.hot.y = -1; 1067a1070,1071 > if ((x != sprite.hot.x) || (y != sprite.hot.y)) > { 1077a1082,1087 > } > else > { > if ((ignoreCache) || (!sprite.win)) > sprite.win = XYToWindow(x, y); > }