Nuevo FiveForm.prg en FWH 12.07

[Antonio Linares]

samples\FiveForm.prg es un diseñador de formularios (ventanas, diálogos) para FWH que automaticamente
genera el código fuente PRG y permite el salvar y cargar formularios a disco. Es un trabajo en desarrollo que iremos completando conforme vayamos recibiendo vuestra información de pruebas, peticiones, etc

FiveForm.prg necesita FWH 12.07 puesto que hemos implementado nuevos métodos GenLocals() y cGenPrg() para que funcione correctamente. Tambien FiveWin.ch ha sido modificado para que todos los controles automaticamente guarden sus nombres de variables en la DATA cVarName.

Por ejemplo, si haceis: @ ..., ... GET oGet1 VAR ...

oGet1:cVarName automaticamente contendrá el valor "oGet1"

[Antonio Linares]

Este es un ejemplo de un cñodigo fuente automaticamente generado desde FiveForm.prg:

Code: Select all  Expand view

#include "FiveWin.ch"

//----------------------------------------------------------------------------//

function BuildWindow()

   local oForm1, oSay1, oGet1, cGet1 := Space( 20 ), oBtn1, oBtn2, oChk1, lChk1 := .F.

   DEFINE WINDOW oForm1 TITLE "Form1" ;
      FROM  21,  61 TO  36, 116

   @  48,  80 SAY oSay1 PROMPT "Say" SIZE  56,  16 PIXEL OF oForm1

   @  48, 160 GET oGet1 VAR cGet1 SIZE 120,  24 PIXEL OF oForm1

   @ 136, 72 BUTTON oBtn1 PROMPT "Button" ;
      SIZE 82, 26 PIXEL OF oForm1 ;
      ACTION MsgInfo( "Not defined yet!" )

   @ 136, 192 BUTTON oBtn2 PROMPT "Button" ;
      SIZE 82, 26 PIXEL OF oForm1 ;
      ACTION MsgInfo( "Not defined yet!" )

   @ 96, 136 CHECKBOX oChk1 VAR lChk1 PROMPT "Checkbox" SIZE 83, 27 PIXEL OF oForm1

   ACTIVATE WINDOW oForm1

return oForm1

//----------------------------------------------------------------------------//

[elvira]

Antonio,

¿Será FW 12.07 compatible con esta sintáxis?

@ 3,75 SAY "&Buscar por:" OF oDlg SIZE 60,10 PIXEL
@ 2,135 GET cGet OF oDlg SIZE 200,10 PIXEL


¿O tendremos que cambiarlo a:?



@ 3,75 SAY oSay PROMPT "&Buscar por:" OF oDlg SIZE 60,10 PIXEL
@ 2,135 GET cGet VAR cMyVar OF oDlg SIZE 200,10 PIXEL



Por favor, es necesario respetar la compatiblidad con la forma de trabajo prexisente. Gracias.

[Bayron]

Hola Elvira,

Ambas formas son aceptadas, al menos con FWH12.04...

Ha pasado ya mucho tiempo desde la ultima vez que lo usé de esa manera, que ya se me ha olvidado...

Las ventajas de usar un objeto para cada SAY son muy grandes, porque puedes manipular el SAY despues de haberlo definido...

[FiveWiDi]

Antonio a ver que te parece esta sugerencia,

Ya se que la he comentado otras veces pero como no sé si ha descartado o no pues ahí "la suelto" otra vez.

Creo que sería muy interesante (sólo le veo ventajas), poder grabar en un fichero la declaración de las variables y en otro la definición en si de la ventana/diálogo.

Yo uso esta manera de trabajar y me va muy bien en el sentido de que me permite tener el código estructurado.

Mis PRG (los que contienen definición de ventanas/diálogos) tienen 5 partes bien diferenciadas:
a) declaración de variables locales
b) asignación de valores a estas variables
c) definción de la ventana/diálogo
d) establecimiento/definición de comportamiento de la ventana/diálogo y/o sus controles.
e) el ACTIVATE de la ventana/diálogo

Así el ejemplo que indicas quedaría de esta manera:

Code: Select all  Expand view

//----------------------------------------------------------------------------//

function BuildWindow()

   #include "oform1.lcl"

   cGet1 := Space( 20 )
   lChk1 := .F.

   #include "oForm1.fwf"

   oform1:bGotFocus  := { || Mifunción( umiparametro) }

   ACTIVATE WINDOW oForm1
return oForm1
//----------------------------------------------------------------------------// 

Y naturalmente el editor que se use para ello deberá detectar que cuando se pulsa (por ejemplo) Ctrl+E, sobre un '#include "oForm1.fwf"' se abrirá el editor del formulario con el formulario indicado.

Ahí lo dejo,

[Carlos Mora]

Sería fantástico que generase código más orientado a objetos, es decir que en lugar de una función generase una clase, y en lugar de locals generase DATAs.
Con eso todas las variables quedan en ámbito dentro de los métodos, queda todo encapsulado permitiéndonos tener, eventualmente, más de una instancia de la misma ventana, y en los métodos tenemos acceso a todas las variables para hacer validaciones, refrescos y otras funciones sin tener que pasarlas como parámetro.
Otra ventaja sería que se podría usar un sistema parecido al que usaba VO, donde había una clase donde estaba el diseño, y una sublcase donde el programador escribía el código, así el FiveForm podria volver a modificar o ajustar el form sin perjuicio del código ya escrito. Serían unas 'variaciones protegidas'.
Esto tal vez requiera algún ajuste ( viewtopic.php?f=22&t=15554 ), pero hoy en día tenemos que pensar orientado a objetos.

Un saludo

[Antonio Linares]

Carlos,

La idea es exactamente la que propones, pero la implementación queremos hacerla de forma escalonada. Me explico

En una primera idea, puesto que usamos un lenguaje "xbase", un diseñador debe ser capaz de generar código xbase que no requiera programación orientada a objetos, ni definición de nuevas clases, etc. Esta es la primera etapa: basada en el preprocesador y generando controles con comandos xbase.

En esta primera etapa hemos usado los métodos GenLocals() y cGenPrg().

En una segunda etapa, el desafío es compatibilizar lo anterior con programación orientada al objeto. Para esto deberíamos tener los métodos GenDatas() y GenMethods(), para que asi se construya una clase derivada a partir de una clase base.

La prioridad principal es mantener la compatibilidad con todo lo existente, no romperle código a nadie ni obligar a hacer cambios. En mi opinión esto es lo más importante: progresar y mejorar en la implementación manteniendo compatibilidad.

Como ejemplo, aunque no venga mucho al caso, es justo lo que NO está haciendo Windows 8. Metro debería ser una capa adicional a lo ya existente, algo nuevo que se pudiese añadir ó no y que no invalidase lo anterior. Nuestras aplicaciones podrían ser Metro ó no, pero sin forzar a descartar lo anterior

[csincuir]

Antonio,
Me parece muy buena esta iniciativa.
Con esto significa que podríamos armar nuestros diálogos, sin necesidad de tener un archivo externo .rc? y contener mucho de nuestros recursos en nuestros .prg?

Saludos.

Carlos.

[elvira]

ntonio,

¿Será FW 12.07 compatible con esta sintáxis?

@ 3,75 SAY "&Buscar por:" OF oDlg SIZE 60,10 PIXEL
@ 2,135 GET cGet OF oDlg SIZE 200,10 PIXEL

[Antonio Linares]

Carlos,

Si, esa es la idea: poder usar esta herramienta para construir ventanas, diálogos, etc.

De hecho te explico como ha nacido: se ha construido para FiveMac y el resultado nos ha gustado tanto que hemos decidido portarla a FiveWin

[Antonio Linares]

Elvira,

Si, mantenemos total compatibilidad con lo anterior

Excepto que el código que genera FiveForm.prg necesita de FWH 12.07 para funcionar correctamente

[Cgallegoa]

Por favor que funcione con xHarbour

Saludos,

Carlos Gallego

[Antonio Linares]

Carlos,

Pues ahi si hay una importante limitación porque FiveForm.prg usa hb_CompileFromBuf() de Harbour y que sepamos a la fecha no existe equivalente en xHarbour...

Esa función se usa para cargar cualquier ventana ó diálogo desde disco, incluyendo el código que tengas en él.

[Cgallegoa]

Antonio,

Claro que sí existe, yo la usa intensivamente Manejo scripts externos compilados y sin compilar. Revisa en el SVN de xHarbour la carpeta UTILS.

Saludos,

Carlos Gallego

[Otto]

elvira,

Será FW 12.07 compatible con esta sintáxis?

@ 3,75 SAY "&Buscar por:" OF oDlg SIZE 60,10 PIXEL
@ 2,135 GET cGet OF oDlg SIZE 200,10 PIXEL

You can use AUTOCODE for this.
Best regards,
Otto