| View previous topic :: View next topic |
| Author |
Message |
Chris Site Admin
Joined: 02 Mar 2004 Posts: 10464
|
Posted: Sat Dec 09, 2006 5:06 pm Post subject: |
|
|
AutoHotkey is currently compiled to be "not aware of terminal server". Although this could be changed, it might break existing scripts that rely on the old behavior. In addition, there's considerable doubt that it would actually help with most terminal server issues (if any).
If anyone is desperate for solution, I can create a version with that setting enabled to see if it makes any difference. |
|
| Back to top |
|
 |
emirvisir
Joined: 07 Dec 2006 Posts: 42
|
Posted: Thu Jan 04, 2007 9:08 am Post subject: |
|
|
I am not "desperate", but it'd be nice to be able to be able to do stuff on the TS rather than "blind" keystrokes, sleeps and clicks. Maybe I could start usin the PStools for some of the things I use this TS for, but for practical purposes it'd be faster for me to be able to see the windows inside the TS...
Thanks for the support,
Miguel |
|
| Back to top |
|
 |
Chris Site Admin
Joined: 02 Mar 2004 Posts: 10464
|
Posted: Wed Jan 10, 2007 4:51 pm Post subject: |
|
|
| emirvisir wrote: | | but for practical purposes it'd be faster for me to be able to see the windows inside the TS... | I'm not sure that Terminal Server "awareness" would provide that functionality. If anyone knows for sure -- or is willing to research it -- please post here. |
|
| Back to top |
|
 |
emirvisir
Joined: 07 Dec 2006 Posts: 42
|
Posted: Wed Jan 10, 2007 4:57 pm Post subject: |
|
|
I would like to try to research that, only that I don't know how to do that. If it's with a special version of ahk, then "bring it on"  |
|
| Back to top |
|
 |
emirvisir
Joined: 07 Dec 2006 Posts: 42
|
Posted: Wed Jan 10, 2007 5:07 pm Post subject: |
|
|
by the way , I found with Winspector that there is a layer of the Terminal Server screen that takes messages with codes very similar to the messages in a normal window (WM_Mousemove and that stuff)
I'll try to analyze these messages. Maybe there is a chance to send some window messages to the Terminal Server, and they will get through to the apps at the other end. There is also info on the cursor that I cannot see with the ahk windowspy.
I'll keep everyone posted... |
|
| Back to top |
|
 |
BoBo Guest
|
Posted: Wed Jan 10, 2007 5:09 pm Post subject: |
|
|
| Quote: | | Maybe I could start usin the PStools for some of the things | Well, PSExec (you need to have Admin permissions on the host to use it). |
|
| Back to top |
|
 |
Chris Site Admin
Joined: 02 Mar 2004 Posts: 10464
|
Posted: Wed Jan 10, 2007 5:45 pm Post subject: |
|
|
Update: Today's v1.0.46.06 is Terminal Server Aware.
Based on the following info, it seems somewhat unlikely that this change will help or hurt anything:
http://msdn2.microsoft.com/en-us/library/01cfys9z.aspx | Quote: | | When an application is not Terminal Server aware (also known as a legacy application), Terminal Server makes certain modifications to the legacy application to make it work properly in a multiuser environment. For example, Terminal Server will create a virtual Windows folder, such that each user gets a Windows folder instead of getting the system's Windows directory. This gives users access to their own INI files. In addition, Terminal Server makes some adjustments to the registry for a legacy application. These modifications slow the loading of the legacy application on Terminal Server. |
Please let me know if you have any problems with it, or discover any benefits.
Thanks. |
|
| Back to top |
|
 |
Chris Site Admin
Joined: 02 Mar 2004 Posts: 10464
|
Posted: Wed Jan 24, 2007 3:10 pm Post subject: |
|
|
No one has said anything about whether this change improves the issues mentioned in this topic. If they do, please let me know because otherwise, I'll probably turn the flag back off for the reasons mentioned at http://www.autohotkey.com/forum/viewtopic.php?t=16041
Thanks. |
|
| Back to top |
|
 |
JBensimon
Joined: 16 Nov 2004 Posts: 130 Location: New York
|
Posted: Thu Jan 25, 2007 5:12 am Post subject: |
|
|
| Quote: | | it seems somewhat unlikely that this change will help ... | You are quite right, Chris: there's pretty much nothing AutoHotkey can ever do to fully manage windows in a remote (RDP or ICA) session from the client side. What appears on the client side is not much more than a "movie" of what's going on in the remote "virtual winstation". While the client area of the (RDP or ICA) client window appears to contain individual application windows, it in fact at any given moment only contains one large bitmap -- there are no individually addressable "objects" in that bitmap. Ever try talking to a movie screen hoping to be heard by one of the characters?
The only available strategies for controlling apps in remote sessions with AHK are:
(1) Send very carefully engineered keystrokes and mouse movements & clicks to the client program window -- if what's going on in the remote session is sufficiently predictable, a certain amount of control over the remote apps can be achieved. Though I haven't tried it, the ImageSearch command might be usable in this scenario to recognize or locate certain windows in the remote session (sounds difficult!).
(2) If you have sufficient access to and permissions on the remote system, you could create and auto-launch a "helper" AHK script within the remote session. This program could perform certain actions (e.g. set the focus on particular windows or shell elements) in response to certain hotkeys, which can in turn be sent to the RDP or ICA client window by the client-side AHK script. Two cooperating AHK scripts, one running on the client and one in the remore session, can achieve things that a single client-side script cannot.
(3) If you're feeling really ambitious, both RDP (from Microsoft) and ICA (from Citrix) offer SDKs for creating new so-called "virtual channels" within the RDP or ICA protocol streams. A new virtual channel is implemented as a custom DLL integrated into the RDP or ICA client software and one or more companion programs (or services) running on the server. A custom "AHK helper" virtual channel could be created to allow client-side AHK programs to "request" information from (or actions in) the remote session. In the end, I think the capability would be pretty much equivalent to (2) above, but a lot harder to implement (for one thing, it would require some sort of "polling" approach because virtual channels are designed primarily for server-side code to send requests to the client-side DLL, not the other way around).
I hope this helps.
Jacques. |
|
| Back to top |
|
 |
|