READ ENVIRONMENT SET

         display "TEMP" upon environment-name

         accept TEMP-Variable from environment-value

Rolf,

you can also call

          call WINAPI ShellExecute using

               by value 0 size 4,          

               by value 0 size 4,

               by reference z"cmd",        

               by reference z"/K set >c:\\temp\\variablen.ini",

               by value 0 size 4,          

               by value SW-hide      

               returning se-hInstance

          end-call

          if se-hInstance < HINSTANCE-ERROR

             set lpszText to address of szText

             add mb-ok

                 MB-ICONINFORMATION

                 MB-DEFBUTTON1

                 MB-SETFOREGROUND

                 MB-SYSTEMMODAL

                 giving uType

             string "SET-Fehler ==>> " kommando

                    delimited by spce into szText

             call WINAPI MessageBox using

                    by value 0 size 4,

                    by value lpszText

                    by reference z"ShellExecute",

                    by value uType

             end-call

          end-if

then you have all the System variables in the .ini.

regards, Georg

This works very good to read the Environment variables set previously.

PROGRAM A:

          DISPLAY "MyValues" UPON ENVIRONMENT-NAME.

          DISPLAY "Rolf" UPON ENVIRONMENT-VALUE.

sets the new ENVIRONMENT-VALUE correctly.

But unfortunately this value is set in an other window, so that a second program does not accept the variable:

PROGRAM B:

          DISPLAY "MyValues" UPON ENVIRONMENT-NAME.

          ACCEPT RECEPTOR FROM ENVIRONMENT-VALUE.

program B returns  an empty string.    

Hello,

If the environment variable is set from the system level or from the same run-unit, then you can read it the way that has been suggested. However, it is not possible to read an environment variable that another program sets since the environment variable can only be visible within that same run-unit. Each program is executed within its own run-unit.

Regards,

More accurately:

On UNIX, each product has an environment, which it inherits from its parent. A process can change its own environment, which will be inherited by any child processes it then creates. Changing the environment in one process does not affect unrelated processes. This is the original implementation of the process environment abstraction.

Windows messed with this model somewhat over the course of various implementations and releases, but it's still largely accurate. Windows complicated things in part by having processes also pick up environment variable settings from various places in the Registry (rather than simply inheriting them), and some Windows programs cheat by re-scanning the Registry environment variable settings and altering their own environment after startup.

But the basic rule remains: once a process is running, only it can change its own environment. You can play tricks like injecting threads into the target process, if you have the necessary permissions, but that's a Bad Idea.