Registrar Formas en Delphi

lpmlpm · #1 26-08-2005

Saludos...

Quisiera saber si existe alguna forma de "registrar" formas en el IDE
de Delphi, de modo que no se requiera agregarlas en el Proyecto (DPR)
actual para poder hacer una derivación de ellas...

Trataré de explicarme mejor... sucede que me he hecho una especie de
Framework GUI con varias clases y ventanas que me ahorran mucho
trabajo y que son de lo más genericas en el desarrollo de un programa
de Base de Datos, es sumamente practico pues se modulariza y
reutilizan cientos (o miles) de lineas de código y es una verdadera
maravilla para proyectos medianos/grandes

Pero esta manera de trabajar tiene el inconveniente de que hay que
agregar muchas clases de formas en el DPR para poder hacer uso de los
beneficios... por poner un ejemplo, tengo algunas de tantas clases
para manejar los reportes mas o menos asi:

TReportePrototipo ---> TReporteSelector ----> TReporteNiveles

y he agregado al repositorio de objetos la clase TReporteNiveles, pero
al crear una nueva clase basada en TReporteNiveles en mi proyecto se
agregan automáticamente las clases abstractas ancestras
TReporteSelector y TReportePrototipo... lo cual es comprensible, pero
al ver la lista de formas del proyecto aparecen todas incluso las
formas que son clases abstractas y que nunca se instancian como tales...

Y cuando ya son muchas las jerarquias que se usan en el proyecto el
DPR y la lista de formas se complica mas de lo deseable, pues se
llegan a ver muchas formas y datamodules que solo se usan como
esqueleto y el que aparezcan ahi en la lista de formas es suceptible
de confundirse y confundir una con otra, etc..., existe algun modo de
hacer un paquete de diseño con estas clases abstractas y usarlas en
Delphi para que pueda encontrar las clases ancestras de mis formas sin
tener que agregarlas propiamente al proyecto??? si es asi como es que
podría hacer eso???...

jmariano · #2 26-08-2005

Tal y como dices al final de tu consulta, puedes hacer un paquete que contenga todos tus formularios abstractos (aunque, eso si, siempre registra los formularios en el repositorio de objetos para que sea más facil, luego, heredar de dichos formularios). Ahora, para que despues puedas trabajar con los formularios heredados en tu aplicación (sin tener que añadir al .dpr toda la lista de formularios abstractos) necesitarás crear un archivo de grupo de proyectos (archivo de extensión .bpg) que incluya tanto el paquete que contenga tus formularios como el archivo de proyecto, .dpr, de tu aplicación (esto es necesario porque Delphi necesita, por decirlo de algún modo, "ver" los formularios abstractos para poder mostrar los formularios que heredan de ellos).

Cuando hayas creado el archivo de grupo de proyectos te aparecerá una ventana, "Project Manager" (seguramente ya la habrás visto), donde tendrás que ir añadiendo los diferentes paquetes y archivos .dpr que formen parte de tu aplicación (o que necesites agrupar). Para ello sólo pulsa el botón derecho del ratón sobre esta ventana (siempre sobre el nombre del archivo de grupo de proyectos) y escoge la opción "Add Existing Project...", después selecciona el paquete que contenga tus formularios abstractos (archivo .dpk) y por último añade el archivo .dpr (aunque el orden, realmente, da igual, lo importante, como te comenté antes, es que añadas los paquetes que el IDE necesite "ver" para poder abrir los formularios o datamodules heredados). Para terminar, acuerdate de guardar el archivo de grupo de proyectos y, siempre que vayas a trabajar con tu aplicación, acuerdate de abrir primero el archivo de grupo de proyectos y después el paquete o .dpr con el que vayas a trabajar realmente. (Para saber más sobre las diferentes opciones de los archivos de grupo de proyectos mira en la ayuda de Delphi).

(Si no comprendiste algo vuelveme a preguntar!)

Saludos!

P.D: Opcionalmente, si quieres, puedes mas tarde enlazar estáticamente el paquete que contiene tus formularios abstractos a la aplicación. (Por cierto, el paquete de tus formularios es mejor que sólo sea de ejecución).

lpmlpm · #3 26-08-2005

Muchas gracias JMariano por tu ayuda,

lo he probado como dices y funciona muy bien, ya puedo eliminar de mi DPR las referencias a los formularios abstractos y puedo editar sus formas "hijas" en el IDE sin problemas... solo sigo teniendo un pequeño detalle...

Una vez que agregué las clases al repositorio de objetos, al heredar de una clase de ahi el IDE me agrega de nuevo las referencias a las clases abstractas al DPR... como le hago para evitar esto???

y otra pregunta, porque dices que mis paquetes tienen que ser de ejecución solamente??

saludos y muchas gracias por el apoyo

jmariano · #4 26-08-2005

Cita:

Empezado por lpmlpm

Muchas gracias JMariano por tu ayuda,

lo he probado como dices y funciona muy bien, ya puedo eliminar de mi DPR las referencias a los formularios abstractos y puedo editar sus formas "hijas" en el IDE sin problemas... solo sigo teniendo un pequeño detalle...

Una vez que agregué las clases al repositorio de objetos, al heredar de una clase de ahi el IDE me agrega de nuevo las referencias a las clases abstractas al DPR... como le hago para evitar esto???

y otra pregunta, porque dices que mis paquetes tienen que ser de ejecución solamente??

saludos y muchas gracias por el apoyo

A la primera pregunta decirte que se trata de un "defecto" bastante molesto en Delphi y que no hay manera de evitarlo (o al menos yo no se como). (En realidad se debe a que Delphi se asegura de que el proyecto o paquete cuenta las unidades necesarias y por eso las añade de forma automática, que, por cierto, siempre las añade al archivo que tengas abierto). Asi que tendrás que eliminar dichas referencias del .dpr manualmente.

A la segunda pregunta me refería a que cuando creas un paquete puedes decidir si este paquete es de ejecución, de diseño o de diseño y ejecución (ve a las opciones del paquete, sección "Usage"). Y como tu paquete no registra componentes ni nada, solo contiene los formularios abstractos, lo mejor es que sólo sea de ejecución (si tuvieras que registrar componentes, entonces, lo mejor sería tener un paquete a parte de sólo diseño que los registrara). (Claro que todo esto sólo tiene sentido si más adelante piensas hacer uso de los paquetes de ejecución a la hora de distribuir tu aplicación).

Bye!

lpmlpm · #5 26-08-2005

Cita:

Empezado por jmariano

A la primera pregunta decirte que se trata de un "defecto" bastante molesto en Delphi y que no hay manera de evitarlo

Ups... ni modo... ya veré como me organizo con eso...

Cita:

A la segunda pregunta me refería a que cuando creas un paquete puedes decidir si este paquete es de ejecución, de diseño o de diseño y ejecución

Ok, pense que tenia algo que ver con eso de que si agregaba o no al DPR las referencias... no, no registro componentes en la paleta, me gusta mas trabajar con Tframes que registrar componentes en la VCL... cuestión de gustos

Gracias por todo

delphi.com.ar · #6 26-08-2005

Te recomiendo leer algo sobre Delphi Open Tools API.

http://www.mustangpeak.net/opentoolsape.htm

Tambien puedes ver el código de las Jedi, que registran sus propios Modules...

Saludos!

jmariano · #7 26-08-2005

Cita:

Empezado por delphi.com.ar

Te recomiendo leer algo sobre Delphi Open Tools API.

http://www.mustangpeak.net/opentoolsape.htm

Tambien puedes ver el código de las Indy, que registran sus propios Modules...

Saludos!

Muchas gracias por la información delphi.com.ar!

Hacía tiempo que buscaba una buena referencia sobre las "Open Tools", pero sólo encontraba información incompleta o pequeños tutoriales que mucho no enseñaban, la verdad. (No entiendo porque este API no viene bien documentado en Delphi, en fins!)

Chao!

delphi.com.ar · #8 26-08-2005

Cita:

Empezado por jmariano

Muchas gracias por la información delphi.com.ar!

Hacía tiempo que buscaba una buena referencia sobre las "Open Tools", pero sólo encontraba información incompleta o pequeños tutoriales que mucho no enseñaban, la verdad. (No entiendo porque este API no viene bien documentado en Delphi, en fins!)

Chao!

Ups!... he borrado esa respuesta, porque después de leer el enunciado completo, me di cuenta que no es lo que buscaba... Me confundió el título, pero vos lo copiaste así que por lo menos sirve de algo

Por otro lado, recuerdo hace tiempo haber echo algo al respecto, registrar mi propio TCustomModule, pero no se donde habrá quedado el código, sino lo subo... era algo mas reducido!

roman · #9 26-08-2005

Cita:

Empezado por delphi.com.ar

Ups!... he borrado esa respuesta, porque después de leer el enunciado completo

Pues yo he recuperado la respuesta. Estaba tratando de recordar ese enlace que pones así que viene muy bien.

Y yo creo que sí que tiene que ver. Hasta donde vi alguna vez, para que esto de formularios base de distintos tipos funcione bien, sin cosas raras, hay que hacer un experto que los registre.

EDITO

Y ya recuperado el mensaje de Federico también he recuperado el de jmariano que le seguía pues viene al caso.

// Saludos

lpmlpm · #10 27-08-2005

Muchas gracias por el link Federico, muy interesante... ya le dedicaré un buen ratito a entender bien la OTA y luego les cuento... y curioso que menciones la suite Jedi, pues es la única que utilizo como componentes de terceros, y es que la calidad de lo que ahi esta hecho es muchisima...

'chas gracias

adlfv · #11 29-08-2005

Hola a todos.

No sé si esto resulta ofensivo o algo así, y me disculpo de antemano si así es.

Me gustaría ver algunos ejemplos de "cómo hacer código genérico" puesto que estoy trabajando en un proyecto y se me ocurrió esa idea (nunca la había aplicado hasta ahora) y me gustaría comparar, y ver si puedo mejorar un poco el código que tengo.

Me pareció muy interesante eso del código genérico. Tal vez se puede hacer algo que realmente valga la pena de cara al programador, para ahorrarnos tiempo, trabajo, y dolores de cabeza depurando.

Muchas gracias de antemano.

Un cordial saludo.

lpmlpm · #12 30-08-2005

Cita:

No sé si esto resulta ofensivo o algo así, y me disculpo de antemano si así es.

No tiene porque ser ofensivo, no te preocupes, para eso se hacen los foros, para comentar, preguntar y dar cada quien sus opiniones...

Cita:

Me gustaría ver algunos ejemplos de "cómo hacer código genérico" puesto que estoy trabajando en un proyecto y se me ocurrió esa idea (nunca la había aplicado hasta ahora) y me gustaría comparar, y ver si puedo mejorar un poco el código que tengo.

Me pareció muy interesante eso del código genérico. Tal vez se puede hacer algo que realmente valga la pena de cara al programador, para ahorrarnos tiempo, trabajo, y dolores de cabeza depurando.

Lamentablemente no te puedo enviar el código que tengo hecho, porque es propiedad de la empresa para la cual trabajo, y por ende no se me esta permitida la divulgación de los fuentes, pero si te puedo platicar un poco de como es que esta hecho lo que tengo y con eso te das una idea...

Para empezar te comentaré que me considero un programador "holgado", osea no me gusta trabajar de mas cuando se puede uno evitar la fatiga, para esto del desarrollo entre menos haya tecleado para obtener el resultado final para mi mejor, por eso es que generalmente me ocupo mas en la parte del diseño de la aplicación que en estar tirando código.

En el tiempo que llevo en esto he visto muchas aplicaciones, unas programadas de manera excelsa y otras mucho mas modestas... por ejemplo he visto sistemas de gestión que funcionan y funcionan bien, pero en cuestión de diseño dejan mucho que desear, pues usan formas para los catálogos donde se repiten una y otra vez las mismas barras de herramientas(sin ser formas heredadas de una forma generica que tenga esa barra de herramientas), donde tienen que estar dandole "Copy/Paste" a las mismas rutinas en cada ventana, porqueal final algo les dice que tienen que comportarse de manera similar, pero su solución es copiar y pegar codigo y componentes de aqui para allá, lo cual trae como consecuencia que la aplicación crezca desmezuradamente, que sea dificil de darle mantenimiento a esa aplicación, y que cualquier observación o requerimiento nuevo haga que el desarrollador se de de topes en la cabeza antes de siquiera intentar hacer un cambio infimo para el cliente, pero que es un esfuerzo garrrafal para el desarrollador por como tiene estructurado el programa.

Cada sistema es un mundo en si y generalmente tiene sus propios requerimientos, pero tambien este que hice hoy va a tener mucho en comun con el que voy a hacer mañana y tambien tiene cosas que pude haber usado en el que hice ayer... la cuestión aqui es saber identificar que es lo que es comun, que es lo que siempre me tengo que chutar a chaleco... y si te pones a pensar son muchas cosas las que son comunmente recurridas... en todos los sistemas queremos generalmente que se puedan identificar los usuarios, que se le puedan asignar permisos individuales y de grupo... en fin va a depender mucho del estilo y necesidades de programación de cada quien determinar las opciones comunes en cada aplicación, en mi caso te puedo mencionar que me gusta que en la aplicación se pueda crear menus personalizados, implementar un escritorio virtual de accesos directos a opciones de la aplicación, poder ver a que y a donde estoy conectado, poder manejar permisos a nivel de catálogos o porque no a nivel de los mismos componentes de los catálogos, (esto ya a gusto y preferencia del cliente final, hay quisquillosos que quieren que fulano pueda entrar al catalogo y modificar lo que sea menos esto u aquello y luego cambian de opinión, etc), me gusta guardar el estado de la última configuración que se uso en cada reporte del programa.. y asi te puedo decir miles y miles de cosas, sobre la seguridad, presentación, prestaciones, manutencion del programa... y lo común es que estas cosas sean como te digo similares en 3 o 4 productos... y si puedo esto manejarlo como un nucleo del cual dependan mis aplicaciones, tendré la ventaja de que una mejora o cambio en el nucleo se verá reflejado automáticamente en la siguiente versión de todos mis productos.

Desde donde yo lo veo, trabajar de esta manera solo tiene ventajas, pues tienes un orden en tu trabajo, es mas sencillo documentar, se puede ser tan específico y tan general como tu lo decidas, y lo único que hay que hacer es trabajar ordenadamente y aplicar algunos conceptos que poca gente respeta y que son tan imprescindibles en la vida real, y estos son: los patrones de diseño.

Hay variada información sobre esto de los patrones en la red, aunque hay poca en Delphi, aqui te dejo una liga para que te enteres de que va este rollo: http://delphi.about.com/od/oopindelphi/a/aa010201a.htm ahi se discuten algunos de los patrones, pero lamentablemente no todos, aunque información sobra en la red si la buscas.

Cuando estudias estas cosas y te das cuenta que la programación orientada a objetos no termina con la herencia sino que realmente ahi es donde empieza y que hay un buen de camino por recorrer al respecto, se te abren muchas puertas a nuevas ideas, y a nuevas perspectivas de atacar los problemas que se te van presentando.

A grandes razgos, y con un grado de abstracción muy alto te he descrito lo que tengo hecho y tambien a mi me gustaría saber que implementaciones hacen otros programadores de este foro, su forma de trabajar, las ideas que nos puedan aportar, su acuerdo o desacuerdo en los patrones de diseño, etc.

Saludos y espero que esto le sea de utilidad a alguien por aqui