|
Windows 10 user and I'm RDPing into my work desktop and I need an app to maintain the connection so that it doesn't time out while I'm doing other things (which means the RDP window is NOT in focus while I'm doing those other things). Basic keep-alives jiggle the mouse or whatever, but that doesn't work on background apps or those windows otherwise not in focus. Is there a keep-alive app out there that you can assign to a particular window even if it's in the background? (NOTE: I'd rather not get into the whole RDP configuration aspect of this; I do not have access to the server side and I tried some client side registry stuff, but it doesn't seem to work for me)
|
# ? Jun 23, 2017 21:12 |
|
|
# ? Apr 26, 2024 04:29 |
|
What you're asking for can't be done with 100% reliability. There are ways to send falsified keyup/down messages to non-active windows, but depending on how the application itself responds to those messages (whether it trusts the message, or whether it queries the keyboard state directly), that approach may not work. Typically, applications that need a better view of what's happening on the keyboard will use more strict checking of the keyboard state, which will quickly make your attempts to fake keypresses to a background app fall apart as the actual keyboard state won't match the fake messages you're trying to send. That said though, you can use PostMessage to send WM_KEYUP, WM_CHAR, and WM_KEYDOWN messages and maybe get away with it; though given the nature of the Remote Desktop Client, I'm not very optimistic it'll work since that feels like an application that's going to want to know the full keyboard state just by the very nature of what it does. What I'd suggest instead is to run your RDP session in a VM, then use a more traditional anti-idle utility within that VM.
|
# ? Jun 23, 2017 21:31 |
|
biznatchio posted:What you're asking for can't be done with 100% reliability. There are ways to send falsified keyup/down messages to non-active windows, but depending on how the application itself responds to those messages (whether it trusts the message, or whether it queries the keyboard state directly), that approach may not work. Typically, applications that need a better view of what's happening on the keyboard will use more strict checking of the keyboard state, which will quickly make your attempts to fake keypresses to a background app fall apart as the actual keyboard state won't match the fake messages you're trying to send. Thank you for taking the time to post this reply -- you do a good job explaining the hurdles involved and I appreciate it. A VM angle as a solution didn't occur to me. Cheers!
|
# ? Jun 23, 2017 21:36 |
|
It's been a while since I did this but can't you just run Mouse Jiggle on the machine that you've RDPed into? i.e. mstsc into Server On that session, run Mouse Jiggle
|
# ? Jun 26, 2017 04:28 |
|
Unfortunately, no, that doesn't work.
|
# ? Jun 26, 2017 07:49 |
|
|
# ? Apr 26, 2024 04:29 |
|
Even with the mstsc /admin switch?
|
# ? Jun 28, 2017 22:35 |