>>>Hi All
>>>
>>>Running an app under terminal services / remote desktop and if I use the Windows Remote desktop Services Manager and look at a logged in user I can see various info about the user such as their log in name but also the "client name" which appears to be the name of the computer that the user is using. For an example see the screenshot attached. Does anyone know an API routine to get that info from within a VFP program?
>>
>>
>>Just as an FYI for anyone interested The solution is incredibly simply and does not require accessing any API. You can retrieve the users computer name under a terminal services session simply using Windows Scripting Host in 2 lines ("doh!"):
>>
>>

>>objShell = CreateObject("WScript.Shell")
>>strClient = objShell.ExpandEnvironmentStrings("%clientname%")
>>? strClient
>>

>>
>>NB: This will only return a valid client name if it is run under a terminal services session. Otherwise you get just "%clientname%".
>
>For your information, WSH is only a wrapper around the APIs. And it's also worth noting that many companies have a policy of blocking WSH, so it's a usually better solution to use the APIs directly..


In some dimensions, full ACK for "better", mostly correlated with shrink-wrapped products.
But for quickly finding out things or as your personal tool kit: why not use Scripting host first, and only when/where blocked use another object where all functionality needed on blocked system is implemented again ? That way the need to go down to API, which often takes longer to implement, is only done when neccessary.

Went that way to overcome the 2 GB barrier inherent in vfp LLF for instance and the perf crossing COM lines for a method call is not that bad in my case: the lines written to file are mostly created for debugging ease to show coherent info (somewhere between chunky and chatty, where chunky will create problems if the strings you build are concateneted too often in separate lines) and the version using scripting host performs measurably better.

If that routine needs to run on a machine with disabled scripting, I will re-implement using WINAPI, but not sooner ;-))


YMMV

thomas