FiveTech Software tech support forums

Hola Amigos:

He decidido poner el código fuente de este projecto en la modalidad de Open Source para poder tener esta herramienta lista en un tiempo razonablemente corto.

Aquí tienen un link para que puedan ver el avance de Visual FiveWin.

http://www.box.net/shared/x6ysuaxc8c

Como podrán observar es todavía una aplicación de 16 bits (hace más de un año que no le pongo la mano encima), pero será muy facil y rápido convertir lo ya realizado a 32 bits.

Me gustaría escuchar la opinión de Antonio para una posible coordinación del proyecto por el mismo FiveTech.

De igual manera, será valiosa la opinión de todos ustedes, especialmente la de aquellos que pudieran contribuír a su realización, me refiero entre otros a mi amigos de Verce, Juan Carlos y William, a Rafa Carmona, así como a los realizadores de algunos controles de terceros como yo mismo, Alfredo Arteaga y otros, quien mejor que ellos sabrán parametrizar los controles para agregarlos al IDE.

Un abrazo.

Manuel Mercado

Manuel

Creo que va siendo tiempo de disponer de un IDE razonablemente decente. Buena idea de continuar con su desarrollo y ponerlo en modalidad de Open Source.

Particularmente estuve modificando algunos programas contenidos en Samples para hacer más sencillo el desarrollo de aplicaciones, y estuve tentado de emprender el desarrollo de un IDE para mi uso personal.

Ahora que un Maestro como tú lo toma (o retoma) no tengo más que felicitarte y si de algo sirve, cuenta conmigo incondicionalmente.

Saludos

Armando

mmercado wrote:Hola Amigos:

He decidido poner el código fuente de este projecto en la modalidad de Open Source para poder tener esta herramienta lista en un tiempo razonablemente corto.

Aquí tienen un link para que puedan ver el avance de Visual FiveWin.

http://www.box.net/shared/x6ysuaxc8c

Como podrán observar es todavía una aplicación de 16 bits (hace más de un año que no le pongo la mano encima), pero será muy facil y rápido convertir lo ya realizado a 32 bits.

Me gustaría escuchar la opinión de Antonio para una posible coordinación del proyecto por el mismo FiveTech.

De igual manera, será valiosa la opinión de todos ustedes, especialmente la de aquellos que pudieran contribuír a su realización, me refiero entre otros a mi amigos de Verce, Juan Carlos y William, a Rafa Carmona, así como a los realizadores de algunos controles de terceros como yo mismo, Alfredo Arteaga y otros, quien mejor que ellos sabrán parametrizar los controles para agregarlos al IDE.

Un abrazo.

Manuel Mercado

Manuel,

El tema de un IDE para fivewin ha sido siempre un tema interesante y "candente".

Si logramos integrar un IDE con Fivewin no hay herramienta xBase que se le pueda parar al lado.

Te felicito por tu decision de continuar con el desarrollo de VisualFivewin ahora como "open source". De seguro vas a tener el apoyo de toda la comunidad 'Fivewinera".

Organizate la forma como se va a trabajar en este proyecto y dinos que tipo de apoyo especifico necesita para llevar a feliz termino VisualFivewin.

Saludos,

George

mmercado wrote:Hola Amigos:

He decidido poner el código fuente de este projecto en la modalidad de Open Source para poder tener esta herramienta lista en un tiempo razonablemente corto.

Aquí tienen un link para que puedan ver el avance de Visual FiveWin.

http://www.box.net/shared/x6ysuaxc8c

Como podrán observar es todavía una aplicación de 16 bits (hace más de un año que no le pongo la mano encima), pero será muy facil y rápido convertir lo ya realizado a 32 bits.

Me gustaría escuchar la opinión de Antonio para una posible coordinación del proyecto por el mismo FiveTech.

De igual manera, será valiosa la opinión de todos ustedes, especialmente la de aquellos que pudieran contribuír a su realización, me refiero entre otros a mi amigos de Verce, Juan Carlos y William, a Rafa Carmona, así como a los realizadores de algunos controles de terceros como yo mismo, Alfredo Arteaga y otros, quien mejor que ellos sabrán parametrizar los controles para agregarlos al IDE.

Un abrazo.

Manuel Mercado

Maestro Manuel,

Creo que lo mejor seria tener un espacio en Sourceforge donde todos los interesados y que tengan ganas de ayudarte podria poner sus actualizaciones y al mismo tiempo tener todas las mejoras. Cada uno seria cadastrado y asi tenemos un equipo bien definido de desarrolladores del proyecto. Que tal?

Saludos,

Bunea iniciativa Manuel, cuenta con mi apoyo y ayuda, en lo que pueda.

La opción que propone Kleyber , creo que es la mejor.

Estimado Manuel,

Muchas gracias por tus excelentes contribuciones, a las que nos tienes acostumbrados

Tu aplicación es sin ninguna duda una herramienta muy práctica y su código fuente es una gran ayuda para adquirir maestria en la programación con FiveWin.

Respecto al diseñador en si mismo, veo que usa el mismo modelo que usó Visual Objects ("herramienta de una sola dirección":"one way tool") que tenía un gran problema: si el usuario quiere modificar un formulario (ventana ó diálogo) despues de que su PRG haya sido modificado con código fuente extra, este código fuente extra se pierde. Esa fué la principal queja acerca del modelo del diseñador de Visual Objects (tambien se implementaron algunas soluciones que podríamos comentar).

La ventaja de usar un fichero de recursos es, como sabes, que si decides modificar el diálogo, puedes hacerlo y no afectará a tu PRG existente, asumiendo que se ha usado un buen estilo de programación en el PRG.

Incluso las herramientas de "dos direcciones:two way tools" implementadas por Borland, tienen el problema que he descrito más arriba. No son lo suficientemente inteligentes para saber que nombres de componentes has cambiado y donde los usabas en tu código y como los estabas usando.

Por lo que mientras los ordenadores no sean más inteligentes que los programadores, tendremos que seguir programando "a mano" como de costumbre

Es mi opinión personal, y por supuesto estamos abiertos a escuchar todas las opiniones.

Antonio,

Sin necesidad ni deseo de crear polemica nos podria informar que metodo usan los otros IDE de xbase.
Me refiero a C3, Visual xHarbour y el S....r
Lo que quisiera saber es si podemos usar la experiencia aqduirida en esos otros entornos para desarrollar nuestro VisualFivewin.

Saludos,

George

George,

Basicamente usan el modelo tradicional de los recursos RC, aunque con modelos propios que incluyen información ampliada de las propiedades de los controles. Por ejemplo, Delphi usa los ficheros DFM, Mac los ficheros NIB, Linux GTK el modelo de Glade, y así un montón de distintos formatos distintos pero muy similares en propósito

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.

Entendido Antonio.

Con esta explicacion y sobretodo con la de tu anterior "post"estamos mas edificado respecto al proyecto VisualFivewin de MM.

Parece ser que Delphi trazo las pautas mas estandarizadas, y que han sido copiadas por otros, en lo que se refiere al IDE/RAD.

George

Antonio Linares wrote:Respecto al diseñador en si mismo, veo que usa el mismo modelo que usó Visual Objects ("herramienta de una sola dirección":"one way tool") que tenía un gran problema: si el usuario quiere modificar un formulario (ventana ó diálogo) despues de que su PRG haya sido modificado con código fuente extra, este código fuente extra se pierde. Esa fué la principal queja acerca del modelo del diseñador de Visual Objects (tambien se implementaron algunas soluciones que podríamos comentar).

Hola Antonioi:

Se agradecen los comentarios, siempre será bienvenida la crítica constructiva sobre todo cuando viene de un señorón de la programación como tú.

Mi conceptualización final de Visual FiveWin tiene considerada la inclusión de todos los elementos que conforman un proyecto hasta llegar al la ejecución misma de la aplicación con el mantenimiento necesario hasta su liberación. Lo que tenga que hacerse, se hará para que funcione bajo esta premisa. No obstante, siempre será conveniente educarnos en el planteamiento modular de nuestras aplicaciones haciendo que los prgs donde se utilizan formularios, involucren el mínimo de código no relacionado con la mecánica del formulario en sí.

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.

Sigo esperando las propuestas (de todos) para el manejo del open source.

Un abrazo.

Manuel Mercado

Nota: Me gustó mucho el comentario de George cuando dice "Nuestro VisualFiveWin", espero que así lo empiecen a considerar todos los FiveWineros aunque participen en el proyecto solamente usándolo y probándolo.

Hola Manuel, yo empecé a desarrollar algo parecido debido a una platica de este foro en la que comentaban que un ide era algo innecesario y que muchos no usarían, no sabía de tu trabajo y menos que lo harías código abierto, para mi mi proyecto ya es un reto personal, que bueno, si no logro que funcione cabiaré por visual fivewin , si quieres verlo por lo menos para comparar y tal vez tomar algunas ideas, puedes ver algo del avance en ftp://ftp.quiquesoft.com/qsvisual.zip, claro no lleva tanto, supongo, como visual fivewin, pero bueno, algo es algo

George,

> Parece ser que Delphi trazo las pautas mas estandarizadas

No, para nada. Ese modelo es mucho mán anterior y antiguo. Mac incorporó el sistema de ficheros NIB ("next interface builder") desde la época de la creación del ordenador de NextStep que fué posterior a cuando Steve Jobs fué expulsado de su propia empresa (Apple) "gracias" al asesor financiero que el mismo contrató

Pero no hay mal que por bien no venga, y para no "aburrirse" construyó los ordenadores "NextStep" y de paso la empresa "Pixar" (si, las películas de animación como "Toy Story"). Y de remate luego le vendió la tecnología de "NextStep" a Apple por un montón de millones y volviendo como CEO.

Los ficheros NIB no sólo contienen información de las propiedades de los objetos, sino relaciones entre ellos en el sentido de eventos y métodos a ejecutar. Además incorpora tecnologías realmente novedosas (que Windows nunca ha llegado a tener) que es el uso de "controladores", que son objetos a los que se le pueden delegar el trabajo de administrar eventos, es decir, no hay un punto único de proceso de mensajes. Sino que puede distribuirse tanto como se quiera. Hay muchísimo que aprender del OSX

Ya ven, a poco que me den pie, me pongo a contar batallitas...

mmercado wrote:... No obstante, siempre será conveniente educarnos en el planteamiento modular de nuestras aplicaciones haciendo que los prgs donde se utilizan formularios, involucren el mínimo de código no relacionado con la mecánica del formulario en sí.

Hola a todos,

Allá por el 2000 empecé en 16b con Clipper+FiveWin; más concretamente y por necesidad, en el desarrollo de un diseñador visual de diálogos y ventanas para FiveWin, se llamó/llama FiveWiDi. De ahí mi nick de usuario.
Una de sus virtudes era que generaba ficheros (.fwd) con el diseño de los formularios y otros con la declaración local de sus variables (.lcl), y estos ficheros los añadía a mano en mis aplicaciones con 2 simples INCLUDE ('include dlg1.lcl' y 'include dlg1.fwd'). FiveWiDi era capaz de leer definición de controles en un % elevado aun haciéndolo de una manera muy bruta.
Además las características de los controles que podía usar FiveWiDi está en ficheros INI, y eso permite crear predefiniciones y agrupaciones de controles (para la aplicación 'x', para la 'y', etc.).

ej. de .FWD:
DEFINE DIALOG oDbfXLS7A TITLE "Exportar dades a XLS" FROM 71,230 TO 367,564 ;
COLORS J02CLRTEXTO,J02CLRWND OF AMPAarra[1][1][2][1][1] PIXEL FONT J02FONTWND //FIVEWIDI

@ 16.00,10.00 SAY oInforme PROMPT "Activat Filtre manual" OF odbfxls7a COLORS ;
J02CLRTEXTO,J02CLRFONDO FONT J02FONTSAY CENTER PIXEL SIZE 148.00,10.00 UPDATE //FIVEWIDI

-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.

ej de .LCL
/* *** Def. Var. FWD *** Window/Dialog: oDbfXLS7A */
Local oDbfXLS7A
Local oCarpeta, uCarpeta
/* *** End Def. FWD *** Window/Dialog: oDbfXLS7A */

mmercado wrote: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.

Yo sigo usando de la misma manera FiveWiDi que tu Visual FiveWin.

La herramienta en si, su código deja mucho que desear (era mi primera aplicación y fue muy duro), pero la idea sigo convencido de que era la correcta y acertada; el código de los formularios es independiente de los PRG, además sus cláusulas son inteligibles sin error posible por el programador (un LEFT es un LEFT no un OF), no son parámetros de una función (como se ha visto en otros diseñadores), los objetos de los controles son deducibles (incluso para el propio IDE), la definición de las cláusulas disponibles estan en ficheros INI que se leen una sola vez y a demanda, etc.

FiveWiDi era sólo una parte de lo que podría ser un IDE como Verce podría ser otra parte y otra un editor 'inteligente' de PRG, otra sería un editor de programación de eventos (ON CLICK p.e.) y otra la de reportes.

Por cierto viendo la arquitectura en FiveWin de heredabilidad entre los controles, con ficheros INI se podría simular esa misma heredabilidad de eventos para saber que NO se pude editar, que se puede editar y con que parámetros y así poder crear 2 ficheros, .EVA y .EVD al que realizar 2 includes justo antes/después de activar el diálogo o ventana, para acabar teniendo 4 ficheros que componen la definición de tu diálgo/ventana:

Manclien.LCL
Manclien.FWD
Manclien.EVA
Manclien.EVD

Si el editor de PRg es lo suficiente inteligente, será fácil decirle donde poner los includes, y que el controle si se han añadido o no.

En fin que me estoy enrollando, no paro de ampliar el mensaje, es tarde, tengo sueño y hasta mañana.
Sólo intentaba dar alguna idea.

Saludos
Carlos G.

Bueno yo conceptualize la creacion de un ide en tiempo de ejecucion con fw y actualmente lo vengo usando en mis desarrollos y consiste en los siguiente

1.El ide no debe de generar codigo *.prg para los formularios
por que si se agrega algun nuevo control el prg queda desfasado
y si actualiza el prg hay lugar a que borre algo del codigo que
retocamos.


2.Las clases de FW deben tener datos que guarden
los nombres de las funciones de nuestras aplicaciones que se disparan en los eventos de los controles.

3.Toda la informacion del formualrio debe grabarse en un archivo yo le puso la extension *.frm donde no solo estaran los datos de las propiedades de los objetos si no tambien el nombre de las funciones de
muestras aplicaciones asociadas a los eventos de los controles

4.Al cargarse el archivo crea el formualrio y sus objetos y como tiene
datos que guardan las funciones asociadas a los eventos hacer un
object inspector es facilisimo solo basta con apuntar al control y ahi
estara toda la informacion.

5.La invocacion de los formularios se puede hacer desde el codigo de
nuestra aplicacion con alguna funcion


Ejemplo

Form("inicio")

Y las funciones asociada a los eventos van despues

Func initinicio

Func validdelget50

Func dobleclicdelbrw60

Es decir el formulario tiene los enlaces con nuestras funciones
de manera que si se agrega un nuevo control solo bastara con
indicar en el disenador cual es el evento y este nos enviara
a digitar en el editor de codigo la syntaxis xharbour.

Func nuevocontrol
msgalert("hiciste clic en este nuevo boton")

6.Una vez acabado el proyecto metemos el *.frm al exe y ya no estaria
accesible para el cliente.

Creo que en la UNION de verdad esta la FUERZA, y porfin todos (o la mayoria) estamos de acuerdo con este GRAN PROYECTO, hemos recorrido un gran camino programando a PIE, es hora de darnos una colita, y dejar que el modernismo nos lleve sin dejar de nosotros dominarlo, mi nivel de programacion no es tanto como para ayudar o aportar en la programacion de VISUAL FIVEWIN, pero creo que como TESTEADOR soy bueno, y creo que entre todos, PROGRAMADORES, TESTEADORES, USUARIOS FINALES y demas aportadores, haremos un GRAN TRABAJO... ahora es que hay FWH para rato....que viva la PROGRAMACION..!