Xailer & OZ Software

Desde estas lineas me gustarí­a dar un par de criticas 'constructivas' al
IDE de Xailer, para una mejor herramienta.
1.- Una única ventana separada las zonas por spliters.
2.- He visto que cuando saquéis la 2.0 tenéis pensado el hacer que
aparezca la ayuda de la función en concreto, seria interesante también
soportar el que auto completado a nivel de clases, me explico.
Cuando presionamos oForm1: , después de los 2 puntos desplegable de los
methods de dicha clase, vamos , como Delphi, NetBeans, etc...
3.-Creo que seria MUY interesante, que cuando se crea un method desde el
IDE, este a parte de completar el METHOD correspondiente, añadiera,
opcionalmente si se quiere, en formato HBDOC como Harbour, la ayuda
de ese method, así­ solamente tendrí­amos que rellenar eso.
Pasado después la herramiento HBDOC tendriamos automaticamente toda la
documentación de nuestra aplicación, una especie de JAVADOC.
Y ahora una mejora a la clase TMenu, que creo que serí­a muy muy
interesante, estoy trabajando en ello, es dotarla de 2 methods;
Load( cStringXML ), Save()
Load() se encarga de cargar un menú a través de un XML.
Save() se encarga de guardar dicho menú en un XML.
Con esto la menús ganarí­an una potencia tremenda, porque , podrí­as
diseñar el menú general, y activar/desactivar opciones, para crear
un menú distinto, sin depender ya de la modificación del código fuente.
Saludos
Rafa Carmona

Rafa,
> 1.- Una única ventana separada las zonas por spliters.
Uff... sobre esto podemos estar hablando mucho mucho tiempo, y al final
veremos que ambas formas tienen sus pros y sus contras. La idea que propones
es la que tenemos funcionando en XEdit
(http://www.xailer.com/files/xedit2.zip), pero porque XEdit es un editor de
código que no incluye un diseñador de formularios.
Pero cuando hay que mostrar tanto el inspector de objetos como el formulario
en diseño, la cosa se complica. Está claro que el inspector de objetos
podría estar en la ventana principal, pero ¿qué pasa con el formulario en
diseño? Algunos IDEs del tipo MS-VS tienen un área central donde muestran
una simulación del formulario. Pero no es un formulario real, lo que puede
llevar a que lo que estamos viendo pueda tener diferencias con lo que
después se verá en tiempo de ejecución.
Por otro lado, cuando está separado en distintas ventanas, hace más fácil su
manejo con varios monitores (sí, algunos podrán decir que el soporte
multimonitor no está al 100% y tienen razón; intentaremos mejorarlo pronto).
En cambio, con una única ventana no se pueden aprovechar varios monitores,
salvo que se abran varias instancias del IDE y se sitúe cada una en un
monitor.
En cualquier caso, me parece bien hablar sobre este tema, y no me importaría
abrir un debate donde todos puedan opinar.
> 2.- He visto que cuando saquéis la 2.0 tenéis pensado el hacer que
> aparezca la ayuda de la función en concreto, seria interesante también
> soportar el que auto completado a nivel de clases, me explico.
> Cuando presionamos oForm1: , después de los 2 puntos desplegable de los
> methods de dicha clase, vamos , como Delphi, NetBeans, etc...
Sí, lo tenemos previsto también. Lo malo es que como el lenguaje no es
'tipado', habrá casos en los que no sea posible averiguar a qué objeto
corresponde una determinada variable. P.ej., en todos los eventos se recibe
como primer parámetro 'oSender', que es el objeto que lanza el evento. Pero
hay eventos genéricos (p.ej. OnKeyDown) donde es prácticamente imposible
saber qué tipo de objeto es oSender desde el IDE.
> 3.-Creo que seria MUY interesante, que cuando se crea un method desde el
> IDE, este a parte de completar el METHOD correspondiente, añadiera,
> opcionalmente si se quiere, en formato HBDOC como Harbour, la ayuda
> de ese method, así solamente tendríamos que rellenar eso.
> Pasado después la herramiento HBDOC tendriamos automaticamente toda la
> documentación de nuestra aplicación, una especie de JAVADOC.
Bueno, ahora mismo tenemos las 'abreviaturas', que permiten insertar un
texto configurable predefinido en cualquier punto. Es más, recientemente se
han añadido 'macros' para hacerlo más versátil. No obstante, lo
estudiaremos.
> Y ahora una mejora a la clase TMenu, que creo que sería muy muy
> interesante, estoy trabajando en ello, es dotarla de 2 methods;
> Load( cStringXML ), Save()
>
> Load() se encarga de cargar un menú a través de un XML.
> Save() se encarga de guardar dicho menú en un XML.
>
> Con esto la menús ganarían una potencia tremenda, porque , podrías
> diseñar el menú general, y activar/desactivar opciones, para crear
> un menú distinto, sin depender ya de la modificación del código fuente.
Sí, es buena idea. Estoy seguro de que muchos de nosotros ya hemos
solucionado el problema de guardar las opciones de menú en algún sitio para
cargarlas en runtime, pero coincido contigo en que sería buena idea tener
esos dos métodos directamente en la clase TMenu.
--
Un saludo,
José F. Giménez
http://www.xailer.com
http://www.xailer.info

Jose F. Gimenez escribió:
> Pero cuando hay que mostrar tanto el inspector de objetos como el formulario
> en diseño, la cosa se complica. Está claro que el inspector de objetos
> podrí­a estar en la ventana principal, pero ¿qué pasa con el formulario en
> diseño? Algunos IDEs del tipo MS-VS tienen un área central donde muestran
> una simulación del formulario. Pero no es un formulario real, lo que puede
> llevar a que lo que estamos viendo pueda tener diferencias con lo que
> después se verá en tiempo de ejecución.
>
Bueno, todo junto, es decir, ventana de propiedades, ventana de menus y
ventana de codigo.
NO OTRA VENTANA PARA DISEí‘O COMO EL Visual Studio , MENUDA MIERDA ES ESO!!
Para que me entiendas, a lo Delphi 7
Saludos
Rafa Carmona