>Hi Ed,
>
>SetEnvironmentVariable() was my first thought, too. But a quick test showed that GETENV() still won't find that variable. Do you have any idea, why?
I believe that VFP doesn't use the matching call GetEnvironmentVariable() on each instance of GETENV(); instead, it seems to do a GetEnvironmentStrings to return the location of the environment block once, and then caches the environment block in its own space, never rereading it after that point.
It's a guess here, but an educated one, based on the fact that FPW 2.6 did something similar (it did a GetDOSEnvironment() and worked from that buffer directly, also refusing to show changes through.) If you do a SetEnvironmentVariable(), invoking GetEnvironmentVariable() returns the correct value. Also, the address returned by GetEnvironmentStrings() changes at times after doing SetEnvironmentVariable(), so if a static pointer were used by VFP, it wouldn't alwayus catch the change.
The real meat of the matter is where I do use SetEnvironmentVariable(), setting up an inheritable environment block for child processes. the child processes inherit the modified or added values, so I'm certain that the API call works as specified; VFP just doesn't work as expected.
It's easy enough to code a replacement for GetEnv() that does the API call; something as simple as:
LPARAMETER cEnvVar
IF TYPE('cEnvVar') # 'C' OR EMPTY(cEnvVar)
RETURN NULL
ENDIF
LOCAL cReturnBuffer, nResult
cReturnBuffer = REPL(CHR(0),256)
nResult = 0
DECLARE INTEGER GetEnvironmentVariable IN WIN32API ;
STRING lpName, ;
STRING lpBuffer, ;
INTEGER nSize
nResult = GetEnvironmentVariable(cEnvVar, @cReturnBuffer, LEN(cReturnBuffer))
IF nResult > 0
RETURN LEFT(cReturnBuffer,nResult)
ELSE
RETURN NULL
ENDIF
Ed