>>>>My Win2K box returns < machine name >#< user name >.
>>>
>>>Is that from FPD/FPW?
>>>
>>>
>>>>I personally wouldn't bother with it, however, if I was only interested in the user name. I'd use either the API or WSH.
>>>
>>>Can I do API or WSH in FPD? In FPW, parsing sys(0) seems easier than API + foxtools.
>>>
>>>Thanks.
>>
>>Sorry, Doru. I didn't check the category. Both FPW 2.6a and FPD 2.5 report < machine name ># < number >. No name IOW. Further, the GetUserName() function was not supported under Win 3.1, so that's out as well. As for the WSH, there's no mechanism to create the object. I've tried, via the RUN command and ShellExecute to run a script file without success.
>
>Actually, there's a sick, twisted approach available (so of course it occurs naturally to me!) Write a WSH Script that emits the user name by instantiating Wscript.Network, and dump it to a file. Encapsulate the running of the script in a batch file, with at least the lines:
>
>

START CSCRIPT.EXE <i>name of your WSH Script</i>
>EXIT

>
>Now, inside your FPW (or FPD) app, fire off the batch file using RUN without the /N parameters - it launches a new instance of the CLI, says "It's a batch file, so I'll run it", and Windows now starts a Win32 VDM to process the batch file. Suddenly, your DOSApp or Win16App can now invoke a Win32 executable. You then suck down the result from the external execution.
>
>BTW, using RUN without the /N makes it run synchronously, so FP doesn't continue until your script finishes running. Be sure that the FOXRUN.PIF has the 'Close on Exit' checkbox marked.
>
>Obviously, the platform must be capable of running the WSH, and have it installed or this doesn't help a bit. The same thing can be used to call a VFP .EXE from within a DOSApp or Win16App.

Doh! Never even thought of that, Ed. Thanks for the heads up.