A var is deemed global unless it is a function parameter or declared 
PRIVATE etc.

In the background all vars are actually tracked as globals and pulled 
into function scope, by reference, as necessary.

In this way the use of the var still looks sort of like the original 
($n_myFormNumber) but is actually using the global var 'by reference'.

References in php can be tricky buggers.

A stack of function calls is maintained, adding and releasing vars as 
necessary.

To demonstrate more clearly let's move the use of the var to within a 
function (and fix wait syntax).

PROC Larry()
VIEW "CUSTOMERS"
PICKFORM n.myFormNumber   ; This is a global variable defined elsewhere 
- no way to know when or how
WAIT TABLE UNTIL "F2", "ESC"
DO_IT!
ENDPROC

n.myFormNumber = 1
Larry()


The generated php:

<?php
function Larry()
{
     extract(P::PROC(__FUNCTION__, [], [], [], false), EXTR_REFS);
     global $n_myFormNumber, $Retval;
     P::VIEW(["CUSTOMERS"], 'false');
     P::PICKFORM($n_myFormNumber); // This is a global variable defined 
elsewhere - no way to know when or how

     $Retval = P::WAIT('table', '', '', ["F2", "ESC"]);
     P::DO_IT('view');
     P::PROCEND();
}

$n_myFormNumber = 1;
Larry();

The extract() call fixes up the current symbol table as set by the 
P::PROC call.

php manual extract() EXTR_REFS option:
Extracts variables as references. This effectively means that the values 
of the imported variables are still referencing the values of the array 
parameter. You can use this flag on its own or combine it with any other 
flag by OR'ing the flags.

the PROCEND call updates the global symbol table eg releasing PRIVATES 
and function parameters created in the function.

The P::PROC stub is:
     /**
      * @param string   $name
      * @param string[] $params
      * @param string[] $privates make new global
      * @param string[] $usevars
      * @param boolean  $closed
      *
      * @return array
      */
     static public function PROC($name, array $params, array $privates, 
array $usevars, $closed)
     {
         self::Log(__METHOD__ . " {$name}");
         return PalFunctionRts::MakeNew($name, $params, $privates, 
$usevars, $closed);
     }

     /** @var PalFunctionRts */
     static private $currFunction = null;

     static public function MakeNew($name, array $params, array 
$privates, array $usevars, $closed)
     {
         self::$currFunction = new PalFunctionRts($name, 
self::$currFunction);
         self::$currFunction->Setup($params, $privates, $usevars, $closed);
         return self::$currFunction->MakeNonGlobals();
     }

Does that help?

- Bernie
On 18/10/17 3:20 am, Larry DiGiovanni wrote:
> Bernie van't Hof wrote:
> 
>> So the result is php, interpreted pal. Translation Target is 100%, 
>> which is not difficult. Replicating the pdox dos code behavior is more 
>> difficult.
> 
> Still struggling.  :-)  The above sentence kind of sums up my confusion.
> 
> Let's say I have a simple script:
> 
> VIEW "CUSTOMERS"
> PICKFORM n.myFormNumber   ; This is a global variable defined elsewhere 
> - no way to know when or how
> WAIT UNTIL "F2", "ESC"
> DO_IT!
> 
> What's the output of this and how do I run it, and what do I see?
> 
>> One could either re-write an app (which would be a on-off), or emulate 
>> paradox. I chose the latter as it maintains all the business logic of 
>> the original app and is re-usable. If re-writing the app you still 
>> have to account for paradox behavior anyway.
> 
> Paradox applications, especially DOS PAL apps, tend to be written in 
> certain ways to accommodate the way Paradox works.  Data is modeled to 
> work in Paradox forms, which does not always promote good modeling.  
> What I am saying here is that retaining the original design is not 
> always a good thing.  ;-)
> 
>> What are you like with javascript? (That's my weakness, among others).
> 
> Fair to middlin'.
> 
> 
> -- 
> Larry DiGiovanni