Q:(Finally Answered) How do you change environment variables? -- wgcs Category Questions
There are two registry paths that store environment variables, one for System variables, and the other for User variables. You can create new variables and change existing variables by modifying the values contained here:HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Control\Session Manager\Environment
HKEY_CURRENT_USER\Environment
- ?wgcs
I presume that environment variables work in the same way as it did in the DOS days. When a program is launched, it gets a *copy* of the environment from the parent process and any change to environment variables would only affect the current process. Changing the parent process' environment usually entailed locating the memory control block for the parent process (typically the command shell) and modifying the environment for that process.
As for why there doesn't seem to be much support for environment variables, I would assume that Microsoft's intent is that you are should be using the registry instead.
-- NaotoKimura
In my testing, NaotoKimura is correct: any Command Prompts or VFP sessions that are currently open don't see the changes... they are apparently using a copy of the environment that was created when their processes were created. However, the changes you make in the registry DO affect any new Command Prompt or VFP session that is started. - ?wgcs
On the other hand, the steps using the Win32 API that are described here: Win32 API & FoxPro SetEnvironment Variables only affect the local copy of the environment variables that are owned by the current process. No other processes see the changes, and the changes are lost when your process terminates.
Is there a simple way to enumerate all the environment variables currently defined? -- Category Questions
Yes - I posted a FAQ on UT that demonstrated this a while ago.Title: How do I retrieve all of the current environment strings (demo pointer use)
Summary: This demonstrates using VFP to handle pointers through the API without using static blocks. The API call Get Environment Strings
() returns an OS-owned block. VFP's GETENV() will retrieve specific environment variables by name - but you need to know the name of the environment variable to retrieve it. The following will return a two dimensional array containing all environment variables. The first column is the variable name, and the second the current value.
DECLARE aEnv[1,2]
? GetAllEnvStrings(@aEnv)
DISP MEMO LIKE aENV
FUNCTION GetAllEnvStrings
LPARAMETER aEnvArray
DECLARE INTEGER GetEnvironmentStrings IN WIN32API
DECLARE SHORT FreeEnvironmentStrings IN WIN32API INTEGER lpszEnvironmentBlock
DECLARE INTEGER lstrcpyn IN WIN32API AS StrCpyN ;
STRING @ lpDestString, ;
INTEGER lpSource, ;
INTEGER nMaxLength
LOCAL nOffset, nEnvironmentBlock, cEnvString, nNumEntries, cEqualPos
DECLARE aEnvArray(1,2)
nNumEntries = 0
cEnvString = ' '
nOffset = 0
nEnvironmentBlock = GetEnvironmentStrings()
DO WHILE LEN(cEnvString) > 0
cEnvString = REPL(CHR(0), 512)
IF StrCpyN(@cEnvString, nEnvironmentBlock + nOffset, 512) # 0
cEnvString = LEFT(cEnvString, MAX(0,AT(CHR(0),cEnvString) - 1))
nEqualPos = AT('=',cEnvString)
IF nEqualPos > 0
nNumEntries = nNumEntries + 1
DECLARE aEnvArray(nNumEntries,2)
aEnvArray[nNumEntries,1] = LEFT(cEnvString,nEqualPos - 1)
aEnvArray[nNumEntries,2] = SUBST(cEnvString, nEqualPos + 1)
nOffset = nOffset + LEN(cEnvString) + 1
ENDIF
ENDIF
ENDDO
=FreeEnvironmentStrings(nEnvironmentBlock)
RETURN nNumEntries
One way would be to copy the variables to a text file using the DOS shell: RUN SET > SETLIST.TXT -- Then, open the file and parse the contents. Anything on a line to the left of the equal ("=") sign is an environment variable. Here's a sample program:
RUN set > setlist.txt
lnFile = FOPEN('setlist.txt')
DO WHILE !FEOF(lnFile)
lcString = FGETS(lnFile)
lcVar = LEFT(lcString, AT('=', lcString) - 1)
? lcVar + ' = ' + GETENV(lcVar)
ENDDO
FCLOSE(lnFile)
-- Michael Reynolds
I found old documentation on MSDN on GetDosEnvironment() which is described as a Win3.11 Function call that has no equivalent in Win32. It also notes that the C function Get Env does not work in DLLs... Is this a limitation in VFP DLLs?Also, the only other function I can find to do a similar thing (I was expecting to find an "Enumerate Environment Variables" function) is ResUtilExpandEnvironmentStrings which is described as: The ResUtilExpandEnvironmentStrings function expands strings containing unexpanded references to environment variables.... but also as Requires Windows 2000 Advanced Server; Windows 2000 Data Center.... Why are environment variables so poorly supported in Windows? - ?wgcs
Okay, Windows Scripting Host offers some hope:
Quote from MSDN:
WshEnvironment Object
Not exposed; accessed through WshShell.Environment property.
Property Description
Item Gets or sets the value of a specified environment variable.
WshEnvironment.Item("strName") = strValue WshEnvironment("strName") = strValue
Count The number of enumerated items.
length The number of enumerated items (JScript).
- wgcs
I discovered today that GETENV("path"), compiled under VFP 9, was truncating the return data string to 256 characters. My web search did not find any existing comments or workaround concerning this issue. I replaced the call to GETENV() with a call to Get Environment Variable
in kernel32 in order to resolve the problem. -- Ken ReederCategory VFP Functions
http://fox.wikis.com - a low-impedance, fat-free Visual Foxpro site. 
- 2010.02.09 01:16:37 AM EST
- 2010.02.09 01:16:37 AM EST