Clarioneros

Acá describo cómo llamar a un exe de clarion desde otro exe clarion pasándole parámetros y que éste último si fue ejecutado sin parámetros haga algo

1. Exe de clarion que llama a los otros (lo uso en un gran menú que solo llama los exes de los grandes submódulos)

run('ACE.exe '&clip(glo:usuario)&','&clip(glo:password)&','&clip(glo:compania)&',1')

2. Programa ACE.EXE que recibe y verifica los parámetros
En el frame del menú principal de ACE.
en el init antes del open files


loc:paso = 0
glo:usuario = command('1')
glo:password = command('2')
glo:compania = command('3')
loc:paso = command('4')

loop
if loc:paso = 0
win:ingreso
end

(luego nuestro código adicional de verificación o lo que necesiten) y dependiendo de éste código BREAK para salir del loop

end

Hola fdiazp,

No es una buena práctica el manejar los parámetros de un exe por posición. No sólo es un punto potencial de fallo sino que, además, es poco claro para el usuario que tenga que invocar al exe y para el código que evalúa la llamada.

Los parámetros con que se invocan a los exes se pueden clasificar en dos tipos,
1) switch
2) datos

Los de tipo switch son aquellos que si existen modifican el comportamiento de la aplicación y, sino, esta trabaja en su modo por defecto
Por ejemplo los parámetros del viejo comando DIR del DOS /s /c /r etc

Los de tipo "datos" son aquellos que aportan valores a ser utilizados por el ejecutable (es el caso de tu ejemplo) y estos deberían ser siempre nominativos es decir responder a un nombre de parámetro.
Usando tu mismo ejemplo sería así:

ACE.EXE usuario=leo password=abcde compania=clarion paso=4 /log

En el código de ACE.EXE
Glo:Usuario = COMMAND('usuario')
Glo:Password = COMMAND('password')
Glo:Compania = COMMAND('Compania')
Loc:Paso = COMMAND('paso')
IF COMMAND('/LOG')
Glo:LogActivo = True
END

De esta forma si se altera el orden de los parámetros en la llamada (por el motivo que sea) el aplicativo funcionará y lo hará correctamente (cosa que no siempre se puede asegurar cuando se trabaja por posición).
Además, si se agregan parámetros (por el motivo que sean) estos NO afectarán a los parámetros actuales.

Como ejemplo de un caso real de fallo por usar la técnica de evaluación de parámetros por posición puedo citar un par de aplicaciones nuestras (aplicaciones de cargadores que hacía años que no se tocaban) que comenzaron a fallar luego de haber incorporado el NetTalk. Por que comenzaron a fallar? porque el NetTalk tiene la "muy mala idea" de usar parámetros (del tipo swtich) para activar sus opciones de log y lo que hace es disparar un SETCOMAND en el constructor de una de las clases lo que provoca que los primeros parámetros que "recibe" el aplicativo sean los del NetTalk y no los que se le pasan al exe y, por lo tanto, falla dado que en COMMAND('1') se supone que recibia el nombre del usuario y a partir de ahora recibe /NetTalkLog (no es exactamente este pero es la idea).

Por último, hay que prestar especial atención a que la información que se pasa por parámetro no contenga comillas (ni simples ni dobles) dado que esto "confundirá" al sistema operativo y el exe recibirá los parámetros truncados.
En vista de esto otra buena práctica es controlar estos casos ya sea no permitiendolos o codificando la información enviada por parámetro en base64, rc4 o cualquier otro algoritmo que resulte apropiado.