FTP | CCD | Buscar | Trucos | Trabajo | Foros |
|
Registrarse | FAQ | Miembros | Calendario | Guía de estilo | Buscar | Temas de Hoy | Marcar Foros Como Leídos |
|
Herramientas | Buscar en Tema | Desplegado |
#1
|
||||
|
||||
Registrar Formas en Delphi
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???...
__________________
"Lo mejor de no saber hacer nada es que se tiene mucho tiempo libre."
Última edición por lpmlpm fecha: 26-08-2005 a las 19:49:41. |
#2
|
||||
|
||||
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). Última edición por jmariano fecha: 26-08-2005 a las 19:29:52. |
#3
|
||||
|
||||
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
__________________
"Lo mejor de no saber hacer nada es que se tiene mucho tiempo libre."
|
#4
|
||||
|
||||
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 (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! Última edición por jmariano fecha: 26-08-2005 a las 20:55:41. |
#5
|
||||
|
||||
Cita:
Cita:
Gracias por todo
__________________
"Lo mejor de no saber hacer nada es que se tiene mucho tiempo libre."
|
#6
|
||||
|
||||
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!
__________________
delphi.com.ar Dedique el tiempo suficiente para formular su pregunta si pretende que alguien dedique su tiempo en contestarla. Última edición por delphi.com.ar fecha: 26-08-2005 a las 22:26:29. Razón: Corrección, cambié Indy por Jedi |
#7
|
||||
|
||||
Cita:
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! |
#8
|
||||
|
||||
Cita:
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!
__________________
delphi.com.ar Dedique el tiempo suficiente para formular su pregunta si pretende que alguien dedique su tiempo en contestarla. |
#9
|
||||
|
||||
Cita:
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 Última edición por roman fecha: 26-08-2005 a las 22:11:38. |
#10
|
||||
|
||||
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
__________________
"Lo mejor de no saber hacer nada es que se tiene mucho tiempo libre."
|
#11
|
|||
|
|||
Subir código
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. |
#12
|
||||
|
||||
Cita:
Cita:
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
__________________
"Lo mejor de no saber hacer nada es que se tiene mucho tiempo libre."
|
Herramientas | Buscar en Tema |
Desplegado | |
|
|
|