Visual FiveWin

[Antonio Linares]

En mi opinión, antes que nada habría que estar de acuerdo en los formatos a usar:

Para guardar "formularios" en ficheros ("serialización") y posteriormente recuperarlos, mi propuesta es usar XML puesto que nos proporcionará la mayor libertad para extender nuestro modelo de serialización tanto como haga falta.

Por ejemplo: Mac OSX usa XML en sus ficheros NIB (ficheros con extensión .pList: "lista de propiedades") en sus aplicaciones.

[Carlos Mora]

Antonio,

De esa manera, intentan separar el "interface" del "código". Aun así, la sincronización "recurso" y "código" es fundamental, ó un simple cambio de nombre de variable (DATA) en el código, puede romper la aplicación.

Pero el cambio de un nombre de variable es similar a cambiar el ID de un control en un recurso. En un caso el enlace es el ID, en el otro es un nombre de variable, con lo que me parece que no hay cambio.
¿A quien no le apareció nunca un error de ID no encontrado o duplicado?

Creo que es lo mismo, en un modelo estamos atentos a los IDs, y en el otro al nombre.

Un saludo,

Carlos.

[Carlos Mora]

Muy acertada la idea de Antonio de que el uso de tecnologías como XML son obligatorias. Con ese criterio mismo no habría que dejar de lado
a la POO. Se me ocurre que el modelo solución será que el IDE producirá código XML, que contendrá la información que hasta ahora
producimos con editores de recursos, y a esto se añadirá la información propia de los aspectos propios de nuestra aplicación,
incluyendo detalles respecto de los controles, variables y las acciones asociadas a los eventos que se producen en el diálogo.

Si el IDE producirá codigo XML, habrá un procesador que transforme ese XML en código xBase o C, y que se vinculará de alguna manera
con el código que nosotros escribamos en el PRG.

Este modelo coincide bastante con lo que plantea Vladimir, a lo que propondría algunos agregados que me parece que ayudarían a controlar mejor el código.

Mirando los IDEs actuales, todos manejan más o menos los mismos conceptos, es decir, una parte del código sobre la que actúa el IDE y otra independiente con el código que escribimos, normalmente asociado a los eventos que se producen en el dialogo/ventana/formulario.

Si a partir del XML generamos una clase, subclase de Dialog/Windows/Form, que implementa los aspectos visuales, podemos
escribir una sublase con nuestro propio código implementando los eventos.
Esto es lo que hacen muchos IDEs, desde Visual Objects hasta Delphi, y es bastante simple de implementar y usar. Tiene la ventaja de que las variables tanto de los controles como de buffers de edición son declaradas en la clase, por lo que nuestros métodos siempre tienen acceso a ellas ( como se dice, "siempre están en ámbito" ) y no hay que declarar variables ni cosas extrañas, ni es necesaria andar haciendo búsquedas de controles por nombre ni cosas parecidas.

En la misma superclase el compilador de XML generará el codigo de la clase, incluyendo no solo las DATAs sino tambien declarará los métodos, aunque los declare de manera virtual. Eso ayuda en el prototipado rápido, y permitiría testear la clase sin haber escrito una sola línea de código.

Por ejemplo, supongamos que el IDE produce el siguiente código XML:

prueba.xml

Code: Select all  Expand view

<FORM>
   </NAME:TIPOIVA>
   </NTOP:6>
   </NLEFT:18>
   </NHEIGHT:212>
   </NWIDTH:140>
   </STYLE: WS_POPUP|DS_MODALFRAME|DS_3DLOOK|WS_CAPTION|WS_SYSMENU|WS_VISIBLE >
   </CAPTION: "Tipos de IVA" >
   <CONTROLS>
      <STATIC>
         </NAME: oSayCodigo >
         </TEXT:"Código">
         </STYLE: WS_GROUP>
         </NTOP:10>
         </NLEFT:12>
         </NHEIGHT:8>
         </NWIDTH:44>
      </STATIC>
      <STATIC>
         </NAME: oSayDescrip >
         </TEXT:"Descripción">
         </STYLE: WS_GROUP>
         </NTOP:25>
         </NLEFT:12>
         </NHEIGHT:8>
         </NWIDTH:44>
      </STATIC>
      <TGET>
         </NAME:oGetTipo>
         </VAR:TIPO>
         </INIT: 0 >
         </PICTURE:"99">
         </STYLE: ES_RIGHT|WS_BORDER|WS_TABSTOP>
         </NTOP:8>
         </NLEFT:68>
         </NHEIGHT:12>
         </NWIDTH:36>
         </VALID:ValidaTipo>
      </TGET>
      <TGET>
         </NAME:oGetDescrip>
         </VAR:DESCRIP>
         </INIT: "                                   " >
         </STYLE: WS_BORDER|WS_TABSTOP>
         </NTOP:23>
         </NLEFT:68>
         </NHEIGHT:12>
         </NWIDTH:132>
         </VALID:ValidaDescrip>
      </TGET>
      <TBUTTON>
         </NAME:oBtnAceptar>
         </TEXT:"&Aceptar">
         </NTOP:117>
         </NLEFT:101>
         </NHEIGHT:15>
         </NWIDTH:45>
         </ACTION:Aceptar>
      </TBUTTON>
      <TBUTTON>
         </NAME:oBtnCancel>
         </TEXT:"&Cancelar">
         </NTOP:154>
         </NLEFT:101>
         </NHEIGHT:15>
         </NWIDTH:45>
         </ACTION:Cancel>
      </TBUTTON>
   </CONTROLS>
</FORM>



Con esto un programa debería generar un código parecido a:

prueba.frm

Code: Select all  Expand view


CLASS _TIPOIVA // FROM ¿TFORM?
   DATA Form
   DATA oSayCodigo
   DATA oSayDescrip
   DATA oGetCodigo
   DATA TIPO
   DATA oGetDescrip
   DATA DESCRIP
   DATA oBtnAceptar
   DATA oBtnCancel

   METHOD New()
   METHOD ValidaTipo() VIRTUAL // Valida un control
   METHOD ValidaDescrip() VIRTUAL // Valida otro control
   METHOD Aceptar() VIRTUAL // Accion asociada a un boton
   METHOD Cancel() VIRTUAL  // idem

END CLASS

METHOD New() CLASS _TIPOIVA

   /*
   </NTOP:6>
   </NLEFT:18>
   </NHEIGHT:212>
   </NWIDTH:140>
   </STYLE: WS_POPUP|DS_MODALFRAME|DS_3DLOOK|WS_CAPTION|WS_SYSMENU|WS_VISIBLE >
   </CAPTION: "Tipos de IVA" >
   */
   @ 6, 18 DIALOG ::Form SIZE 140, 212 CAPTION "Tipos de IVA" STYLE WS_POPUP|DS_MODALFRAME|DS_3DLOOK|WS_CAPTION|WS_SYSMENU|WS_VISIBLE
      /*
      <STATIC>
         </NAME: oSayCodigo >
         </TEXT:"Código">
         </STYLE: WS_GROUP>
         </NTOP:10>
         </NLEFT:12>
         </NHEIGHT:8>
         </NWIDTH:44>
      </STATIC>
      */
      @ 10, 12 SAY ::oSayCodigo PROMPT "Código" ...

      .... más controles
      /*
      <TGET>
         </NAME:oGetTipo>
         </VAR:TIPO>
         </INIT: 0 >
         </PICTURE:"99">
         </STYLE: ES_RIGHT|WS_BORDER|WS_TABSTOP>
         </NTOP:8>
         </NLEFT:68>
         </NHEIGHT:12>
         </NWIDTH:36>
         </VALID:ValidaTipo>
      </TGET>
      */
      @ 8, 68 GET ::oGetTipo VAR ::TIPO PICTURE "99" STYLE ES_RIGHT|WS_BORDER|WS_TABSTOP VALID ::ValidaTipo()

      ... mas controles

      /*
      <TBUTTON>
         </NAME:oBtnAceptar>
         </TEXT:"&Aceptar">
         </NTOP:117>
         </NLEFT:101>
         </NHEIGHT:15>
         </NWIDTH:45>
         </ACTION:Aceptar>
      </TBUTTON>
      */

      @ 117, 101 BUTTON ::oBtnAceptar SIZE 45, 15 ACTION ::Aceptar()

RETURN Self



Además, si no existe prueba.prg lo crea con el siguiente código

prueba.prg

Code: Select all  Expand view


CLASS TIPOIVA FROM _TIPOIVA
   METHOD ValidaTipo()
   METHOD ValidaDescrip()
   METHOD Aceptar()
   METHOD Cancel()
ENDCLASS

METHOD ValidaTipo() CLASS TIPOIVA
RETURN .T.

METHOD ValidaDescrip() CLASS TIPOIVA
RETURN .T.

METHOD Aceptar() CLASS TIPOIVA
RETURN NIL

METHOD Cancel() CLASS TIPOIVA
RETURN NIL



Dejándonos el código listo para seguir programando.
Algo interesante es que desde dentro de los métodos podemos acceder a cualquier control o variable, ya que son DATAs del método que se está ejecutando. Y seguimos teniendo la independencia que ya tenemos con los recursos, entre los aspectos visuales del form y el código de la aplicacion propiamente dicho.
Tambien hasta se podría ejecutar el código de la clase _ que no hará nada, pero sería como la funcion de test que tiene el PellesC para los dialogos.
Esto se corresponde con un patron de programación GRASP, variaciones protegidas, que tiene muchos usos en temas visuales de la programación.

Un saludo,

Carlos.

[Carles]

Hola Manuel,

No puedo bajar el codigo fuente desde http://www.box.net/shared/x6ysuaxc8c . Hay algun problema ?

Hola Carlos -> Muy buena la explicacion

Hola Antonio -> Seria bueno q coordinases junto a Manuel las bases y arrancar esta propuesta...




Saludos.
C.

[nazariosn]

Como mencionaba en alguna pregunta en el foro inglés, yo uso actualmente Visual FiveWin de manera intensiva en el diseño primario de mis formularios y ya me resulta de una gran utiliidad por el gran ahorro de tiempo en el diseño y en una buena parte del tecleo de mis prgs.

De igual forma desarrolle en el 2002 "genera" (muy rudimentario) para pasar de Clipper-DOS, me es muy util para enseñar FW a mis compañeros (no es comparable con el desarrollo de VFW).

Ahora es necesario el apoyo de TODOS para hacer el VFW de cada día y me uno a para poder probar los avances conforme me sea permitido participar.

Saludos desde la Ciudad de México.

[mmercado]

No puedo bajar el codigo fuente desde http://www.box.net/shared/x6ysuaxc8c . Hay algun problema ?

Hola Carles:

Prueba desde aquí:
http://www.box.net/shared/tosobbh8gg

Saludos.

Manuel Mercado

[Manuel Valdenebro]

Hola Antonio -> Seria bueno q coordinases junto a Manuel las bases y arrancar esta propuesta...

Antonio,

Creo que el proyecto es muy importante y me uno a la opinión de Carles, que debes liderar (junto a Manuel Mercado) este proyecto.
Con el fin unir fuerzas, quizás sería conveniente crear un nuevo foro MULTILENGUA, para el proyecto y no tener que ir del foro español al ingles para ver las aportaciones.

[Antonio Linares]

Manuel,

Es un proyecto que debe apoyarse tanto desde FiveTech como desde los usuarios, que han de solicitar y probar lo que quieren usar.

Y es importante que los usuarios comprendan que para apoyar nuevos proyectos, han de apoyar a los programadores y a FiveTech.

Una forma directa de hacerlo es actualizandose a nuevas versiones del producto. Estar aún con la versión FWH 2.7 Abril 2006 no es apoyar nuevas iniciativas

[Carles]

Hi Antonio,

Bueno, no me gustaria a mi ver ahora nuevas guerras. Antonio, intento compronder tu punto de vista, claro, pero intenta ahora verlo asi: Personalmente no creo en los IDE (sera porque soy de la vieja escuela y creo q siempre es necesario rascar y rascar codigo) pero si q puede dar un plus a FWH. Si se crea este proyecto mucha gente se benefciara de el. Muchos quiza se aprovechen de la iniciativa, otros lo apoyaremos como una vieja espina clavada, otros miraran de sacar un valor añadido al producto, pero ahora creo q lo importante es que alguien (MM), por lo que sea ha entrado en un momento quizas en q muchos creemos.

Muchos hemos y estamos en diferentes proyectos, pero creo q ahora es un buen momento para iniciar uno asi y quien mejor q tu para crear estas bases. Podemos discutir como debe de ser el IDE, dejar una arquitectura abierta a futuras opciones, entrar en nuevas tecnologias como XML, si usaremos un CVS o el SVn para el proeyecto, yo q se ahora... pero el objetivo es conseguir algo que todos saldremos beneficiados y tambien tu Antonio. Muchos estamos siempre por aqui y ahora creo que hay mucho nivel para participar en un proyecto de estas caracteristicas, pero necesitamos tambien tu punto de vista para salir todos beneficiados.

Ademas, estoy seguro q muchos si quieren utilizar el IDE, tendran de pasar al final por una actualizacion de tu producto para q pueda usarlo sin problemas. Ya ves, todos ganamos. Personalmente q gano ?. Durante años me jode que cuando vienen mis colegas Alemanes, flipan con los montajes en FWH, pero ven un palo o no entienden esta manera de trabajar: tus ficheros editados con un simple editor, tus .bat de compilaciones, ..., es q son tan burros q les parece arcaico. Pues ala, quereis un IDE, pues tomad. (Mi editor de prg es QEdit de 50 Kb., como quieres q lo entiendan).

En fin, me voy a tomar una cervesita q pega una 'caló' ...

Nice weekend.
C.

[Antonio Linares]

Carles,

En palabras de Gandhi:
"Hay que ser coherente en lo que se piensa, se dice y se hace"

[Andrés González]

Sr. Mercado, despues de un mes un poquito complicado con mis examenes de la universidad por fin tengo un rato para meterme en el foro y ver una de esas maravillas que estoy acostumbrado a ver en sus publicaciones. Hoy lo he instalado y veo que no me deja pasar del inicio puesto que me sale el mensaje "Sorry, can create Debug file", que problema tengo, que es lo que tengo que hacer para poderlo solucionar?

Por otra parte y sin entrar en polemicas creo que es el momento de empezar a construir las bases para un futuro mejor con fivewin. Aun conservo los disketes de la version primera que salió y mucho hemos avanzado desde entonces. Muchos de nosotros somos el enamorado infiel del fivewin, ya que sin dejar de lado al fivewin siempre hemos tenido el ojo en esos programas que parece que te lo hacen todo, pero no nos acaban de convencer y siempre volvemos al fivewin puesto que nos sentimos comodos con ese entorno aunque reudimentario pero eficiente y que hemos visto crecer por nuestras exigencias y recomendaciones. Ahora es el momento de que esto empiece a mejorar y por lo que veo también Antonio ya piensa en ello puesto que tiene bien presentes las opciones de este tipo de programas. Pero por otra parte he visto que muchas de las iniciativas que se han hecho para crear este tipo de programas han quedado en poca cosa o en una variación hacia otras estructuras xbase que se han desvinculado de fivewin. Por lo tanto y ya que por lo leido parece que todos estamos de acuerdo en empezar a trabajar para disponer en fivewin de esta tecnologia, creo deberia ser un proyecto fivewin y ahi si creo que todos nos pondriamos de acuerdo en encontrar una metodologia de trabajo para crear el visual fivewin del futuro.

Como mi jefe dice en esta vida lo importante no es lo que deseas o te mereces sino lo que realmente consigues, asi que creo que ya es hora de empezar a dar los pasos oportunos para intentar conseguir el tan esperado visual fivewin.

[George]

Muchos de nosotros somos el enamorado infiel del fivewin, ya que sin dejar de lado al fivewin siempre hemos tenido el ojo en esos programas que parece que te lo hacen todo, pero no nos acaban de convencer y siempre volvemos al fivewin puesto que nos sentimos comodos con ese entorno aunque reudimentario pero eficiente y que hemos visto crecer por nuestras exigencias y recomendaciones.

Andres,

Estoy 100% de acuerdo contigo.

Saludos,

George

[quique]

Hola Andy, he estado tratando de coincidir contigo por el msn para enseñarte un proyecto que tengo alterno a visualfivewin pero no lo he conseguido, puedes bajarlo de ftp://ftp.quiquesoft.com/qsvisual.zip a ver cuando podemos coincidir por que tenemos algo pendiente.

[mmercado]

Sr. Mercado, despues de un mes un poquito complicado con mis examenes de la universidad por fin tengo un rato para meterme en el foro y ver una de esas maravillas que estoy acostumbrado a ver en sus publicaciones. Hoy lo he instalado y veo que no me deja pasar del inicio puesto que me sale el mensaje "Sorry, can create Debug file", que problema tengo, que es lo que tengo que hacer para poderlo solucionar?

Hola Andrés:

Que raro, ese mensaje es solo una advertencia y no impide el funcionamiento del programa, instalaste Visual FiveWin con Setup.exe?

Saludos.

Manuel Mercado

[jacgsoft]

Mi modesta opinion es que FiveTech deberia ser quien realize el proyecto y que el IDE se venda con FiveWin(Obviamente con la ultima version de ese momento y en adelante), por lo tanto todos estaremos en la obligacion de actiualzarnos(como dice Carles).

Por otro lado los usuarios de Fivewin y los que tienen ya un IDE construido, deberian apoyar con Ideas para agilizar el proyecto.

Soy de los usuarios que se resisten a usar un IDE(talvez no encontre el Ideal) Pero se que un IDE para FiveWin de todas maneras sera un PLUS para toda la comunidad FiveWinera y para el propio FiveWin.


¿Que dices Antonio te animas a Crear el IDE para FiveWin?


Saludos a la comunidad FiveWinera.

Jaime