>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:

*FUNCTION GetEnvVar
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