workaround for MSTSC window minimization curse
in [Terminal Services]
|
Prev: !!! Oracle Reports rwrbe60.exe on Windows 2003 R2 x64!!!
Next: !!! Oracle Reports rwrbe60.exe on Windows 2003 R2 x64 !!!
From: jolteroli on 1 Dec 2008 13:07 "Andrey" <andrey.fedyashov(a)gmail.com> schrieb im Newsbeitrag news:6ff3c5a5-b75e-49d4-9da6-fb84da39f2ab(a)k19g2000yqg.googlegroups.com... > On Nov 28, 7:06 pm, "jolteroli" <jolt1...(a)gmx.net> wrote: >> Im not sure, but i think GetCursorPos fails, because the Terminalserver >> maintains 3 desktops: >> >> 1.) Logon >> 2.) Interactive Desktop >> 3.) Disconnected Desktop >> >> For sure when disconnected and perhaps when output suppression is active, >> the server switches to the "disconnected desktop". >> > > I think that if this is something that breaks applications running in > this session - then server shouldn't have done that. Why would apps > have to depend on whether remote user has minimized his client screen > or disconnected? Actually the whole design of gui programs in Windows is to be event driven. On user action, the program will get the message and act on that. This won't happen if the mstsc window is minimized, so it should not be a problem when the session switches to the discon-desktop, FOR USUAL APPLICATIONS. No event, no action. Guess the disconnected desktop doesn't have a cursor... >> Have a look >> here:http://www.microsoft.com/msj/1298/terminalserver/terminalserver.aspx >> (Windowstations and Desktops ) >> >> Again curious: What kinda application does use Get/SetCursorPos? In my >> early >> days, we have coded4fun with the Glide API for the 3Dfx Voodoo Cards. We >> have hidden the cursor and got the mouse dx/dy only by the Get/Set calls, >> so >> we had the free look with the mouse, like in Quake3 and such games. > > I think the answer is quite simple - GetCursorPos is an easy to use > function that tells the cursor position on the screen. > Also I can add that it is a must have function for applications > performing mouse and keyboard input generation (like for example > automated functional/UI testing tools). > I am trying to see whether GetCursorInfo can be used as a workaround - > but not sure whether it works reliably in the same conditions. Aha, ok. May be the GetCursorInfo succeed... it's worth a try, anyway! >> Shouldn't workarounding the "bug" this way work? >> >> // current and center coordinates. >> // where mpt is already set to the center and is updated on WM_RESIZE >> msgs. >> POINT pt, mpt; >> >> if (!GetCursorPos(pt)) { >> // Error means no mouse movement happend! >> dx = dy = 0; >> } else { >> // Get deltas'n'update >> dx = pt.x - mpt.x; >> dy = pt.y - mpt.y; >> // set cursor back into the center for next delta. >> SetCursorPos(mpt); >> } >> >> // Go on with dx,dy... >> >> -jolt > > I didn't quite understand this workaround.. You assume that > GetCursorPos failure indicates that there was no mouse movement? Why? This were a workaround for playing Q3-like games on the disconnected desktop :D If there is no cursor, it can't have moved! But this example has nothing to do with your program design. You rely on getting the exact position. May be you are better off, when you contact microsoft support. -jolt
From: Andrey on 10 Dec 2008 10:22 On Dec 1, 8:07 pm, "jolteroli" <jolt1...(a)gmx.net> wrote: > "Andrey" <andrey.fedyas...(a)gmail.com> schrieb im Newsbeitragnews:6ff3c5a5-b75e-49d4-9da6-fb84da39f2ab(a)k19g2000yqg.googlegroups.com... > > > > > On Nov 28, 7:06 pm, "jolteroli" <jolt1...(a)gmx.net> wrote: > >> Im not sure, but i think GetCursorPos fails, because the Terminalserver > >> maintains 3 desktops: > > >> 1.) Logon > >> 2.) Interactive Desktop > >> 3.) Disconnected Desktop > > >> For sure when disconnected and perhaps when output suppression is active, > >> the server switches to the "disconnected desktop". > > > I think that if this is something that breaks applications running in > > this session - then server shouldn't have done that. Why would apps > > have to depend on whether remote user has minimized his client screen > > or disconnected? > > Actually the whole design of gui programs in Windows is to be event driven. > On user action, the program will get the message and act on that. This won't > happen if the mstsc window is minimized, so it should not be a problem when > the session switches to the discon-desktop, FOR USUAL APPLICATIONS. No > event, no action. Guess the disconnected desktop doesn't have a cursor... > Sure, but usual applications might also have a timer and use GetCursorPos on WM_TIMER messages. > > > >> Have a look > >> here:http://www.microsoft.com/msj/1298/terminalserver/terminalserver.aspx > >> (Windowstations and Desktops ) > > >> Again curious: What kinda application does use Get/SetCursorPos? In my > >> early > >> days, we have coded4fun with the Glide API for the 3Dfx Voodoo Cards. We > >> have hidden the cursor and got the mouse dx/dy only by the Get/Set calls, > >> so > >> we had the free look with the mouse, like in Quake3 and such games. > > > I think the answer is quite simple - GetCursorPos is an easy to use > > function that tells the cursor position on the screen. > > Also I can add that it is a must have function for applications > > performing mouse and keyboard input generation (like for example > > automated functional/UI testing tools). > > I am trying to see whether GetCursorInfo can be used as a workaround - > > but not sure whether it works reliably in the same conditions. > > Aha, ok. May be the GetCursorInfo succeed... it's worth a try, anyway! > > > > >> Shouldn't workarounding the "bug" this way work? > > >> // current and center coordinates. > >> // where mpt is already set to the center and is updated on WM_RESIZE > >> msgs. > >> POINT pt, mpt; > > >> if (!GetCursorPos(pt)) { > >> // Error means no mouse movement happend! > >> dx = dy = 0; > >> } else { > >> // Get deltas'n'update > >> dx = pt.x - mpt.x; > >> dy = pt.y - mpt.y; > >> // set cursor back into the center for next delta. > >> SetCursorPos(mpt); > >> } > > >> // Go on with dx,dy... > > >> -jolt > > > I didn't quite understand this workaround.. You assume that > > GetCursorPos failure indicates that there was no mouse movement? Why? > > This were a workaround for playing Q3-like games on the disconnected desktop > :D If there is no cursor, it can't have moved! But this example has nothing > to do with your program design. You rely on getting the exact position. I understood, it allows player to connect and disconnect without leaving the game - the player just stands still and probably dies from a headshot :) > > May be you are better off, when you contact microsoft support. > > -jolt I found this link which summarizes information that I've collected this far: http://www.mjtnet.com/msfaq171.htm seems like those guys had the same issues with tools that generate mouse/keyboard input. -- Andrey
From: jolteroli on 10 Dec 2008 16:39
> Sure, but usual applications might also have a timer and > use GetCursorPos on WM_TIMER messages. Such coders probably take a lot of drugs, like they do in Fear & Loathing in Las Vegas. > I understood, it allows player to connect and disconnect > without leaving the game - the player just stands still and > probably dies from a headshot :) Certainly, the player is protected while that. I'm currently in negotiations with EA, no details on that ;) And anyway gd' luck with the "bug" -jolt |