![]() |
![]() |
![]() |
![]() |
![]() |
FTP | ![]() |
![]() |
CCD | ![]() |
![]() |
Buscar | ![]() |
![]() |
Trucos | ![]() |
![]() |
Trabajo | ![]() |
![]() |
Foros | ![]() |
|
Registrarse | FAQ | Miembros | Calendario | Guía de estilo | Temas de Hoy |
![]() |
|
Herramientas | Buscar en Tema | Desplegado |
#1
|
|||
|
|||
Componentes NO Visuales "Opinion"
Queria sus Opiniones o Sugerencias al Siguiente planteamineto:
Yo soy un de esos programados que trata de utilizar a los componentes nativos de Delphi en su maxima expresion, tengo aplicaciones ya casi listas de un gran numero de formularios,,, pero bueno esto es solo preambulo,,, la pregunta es la siguiente, tengo formularios que tiene muchos "Componentes NO Visuales" osea utilizo muchos TibDatasets y TibQuerys , muchos con Datasource, Tmenues, Timageslist,, etc,etc, No existe una posibilidad como Ocurre con Visual Studio que estos componentes no Estorben en el Diseño del formulario, yo ya estoy como acostumbrado, pero a veces tener muchos de ellos a la hora de Rediseñar algo, hay que mover un monton de ellos para ver como queda el formulario. |
#2
|
|||
|
|||
Sí sí.
Eso que buscás se llama Data Module. Para crear uno vas a File->New->Other. En Other buscás la sección Delphi Files. En esa sección está el Data Module (si tenés un IDE como RAD Studio 2010 que acepte busquedas, solamente busca Data Module). Es una Unit comunacha visual en diseño y no visual en ejecución. Probala ![]() |
#3
|
||||
|
||||
También puedes mirar aquí, donde mencionan lo siguiente:
TLMDHideNonVC This small but useful component allows to hide non visual components on your form. This feature is specially useful when dozens of TDataSources or TTables are used on one form. Nevertheless this component provides full access to all properties and editors of the hidden components.
__________________
Germán Estévez => Web/Blog Guía de estilo, Guía alternativa Utiliza TAG's en tus mensajes. Contactar con el Clubdelphi ![]() P.D: Más tiempo dedicado a la pregunta=Mejores respuestas. |
#4
|
|||
|
|||
Parece que ese TLMDHideNonVC que nos muestra Neftali es idéntico al DataModule de Delphi. Lo digo solo leyendo la breve descripción, no lo probé.
Otra forma de hacerlo (como hacían unos chicos de la facultad a los cuales yo ayudaba con delphi) es poniendo un nuevo formulario con su propiedad Visible en False, y ahi meterle todas las cosas. Era muy feo ver que usen un formulario así, sobretodo sabiendo que yo les explicaba como usar el DataModule. Probá el TLMDHideNonVC y decinos si es lo que necesitabas, así ya lo tengo presente para otro momento ![]() Saludos! |
#5
|
||||
|
||||
Te tiro otra alternativa: CnWizards
Es un plugin para Delphi que agrega muchas cosas, entre ellas, un botón para esconder/mostrar los componentes no visuales. Tiene la ventaja de que no tenés que tocar to proyecto en lo más mínimo, y la desventaja de que instala un montón de cosas. |
#6
|
|||
|
|||
Gracias por sus opiniones
1.- La opcion del DataModule, no es la que me convengan ya que tengo muchas Funciones en mis formularios bases, que necesitan los componentes creados en el formulario. 2.- La opcion de LMD Tools,,trate de bajar el componente y no pude bajarlo (No supe) no encontre en la Pagina como hacerlo.. 3.- La opcion CNWizards seria la ideal, la baje y voy a probarlo a ver que tal.. Saludos |
#7
|
||||
|
||||
Mi opinión:
La opción 1 es la única opción que conviene. Verás: un módulos de datos no es meramente un repositorio de los componentes que nos estorban. Los módulos de datos nos sirven para mantener un código limpio y fácil de mantener. Es la herramienta para la sana separación entre el código de acceso a los datos y el código de interfaz visual. En un formulario, el único componente no visual relacionado con datos que deberías tener es un DataSource. En un formulario no debería haber ningún código relacionado con la lógica de negocios; únicamente debería haber código relacionado con interfaz de usuario: habilitar controles, pintarlos de colores, cambiar de foco, etc. // Saludos |
#8
|
||||
|
||||
Me adhiero casimiro. Es una mala práctica (desgraciadamente Delphi es tan bueno que lo permite) el meter componentes de datos y demás en un formulario, para ello los datamodules asi queda totalmente separado el acceso. Ya si de repente por ahi se cuela una que otra form que utiliza querys únicos que no se accesan en ningún otro lado es adecuado hacerlo así, pero por lo que mencionas parece que tienes muchísimos componentes.
Yo en lo personal creo un panel con alineacion "bottom" y ahi pongo los botones del form, y en ese espacio que se crea pongo los componentes de datos (si los hay) para que como tu dices "no estorben" en el diseño. En efecto es más cómoda la forma como los coloca VB pero obviamente no podrás hacer tantas cosas como puedes con Delphi usando los mismos componentes.
__________________
AKA "El animalito" ||Cordobés a mucha honra|| |
#9
|
||||
|
||||
#10
|
||||
|
||||
jajaja....perdon roman, es lo que pasa cuando ves varios post al mismo tiempo...a ver si no le puse a casimiro..."sí roman, de acuerdo"...jejeje
__________________
AKA "El animalito" ||Cordobés a mucha honra|| |
#11
|
||||
|
||||
Yo también me adhiero a lo dicho por roman y lo que piensa casimiro
![]()
__________________
La otra guía de estilo | Búsquedas avanzadas | Etiquetas para código | Colabora mediante Paypal |
#12
|
|||
|
|||
Yo no quise opinar porque parecería que hago alabanzas a mi solución.
Pero ahora que todos opinan lo mismo, me sumo y reafirmo que para mí esa es la mejor opción. Sobre todo porque es una parte de Delphi, no es un tercero. Saludos. PD: sin ánimos de desestimar los aportes de los demás, todo suma ![]() |
#13
|
||||
|
||||
Ah, no, no, no. Si me vas a venir a tirar abajo a mis ideas...
![]() Es verdad que lo del DataModule es la mejor opción, pero bueno, entro lo mejor y lo que uno tiene ganas de hacer aveces hay mucha diferencia... ![]() |
#14
|
||||
|
||||
Creo que es un poco incorrecta tu apreciacion Delfos, pues mal haríamos y de nada serviría decirle al usuario como proceder sabiendo que es algo incorrecto, simplemente estariamos abonando a la ignorancia que el mencionarle porque no es por ahí, de cualquier forma si el usuario confirma que entiende nuestras advertencias pero aún así quiere seguir por tal o cual lado nadie le va a negar la ayuda.
__________________
AKA "El animalito" ||Cordobés a mucha honra|| |
#15
|
||||
|
||||
Lo que comenta Lord Delfos sobre cnwizards está muy bien, yo lo uso a veces para ver cómo queda el formulario sin esos componentes visuales de por medio
![]()
__________________
La otra guía de estilo | Búsquedas avanzadas | Etiquetas para código | Colabora mediante Paypal |
#16
|
|||
|
|||
Lo que aporta el amigo Lord Delfos es algo interesante, sobretodo pensando que los componentes de terceros muchas veces agregan funcionalidades no aplicadas por Delphi. Es decir, delphi no aplica X funcionalidad, pero un componente ClubDelphi sí.
Siempre es mejor utilizar componentes propios de Delphi, mientras cumplan con el total de requisitos. Cuando ningún componente de Delphi cumple al menos 1 requisito, es totalmente recomendad usar un componente de tercero (porque ese tercero se tomó el tiempo de hacerlo lo más simple y eficaz posible). Siendo sintético, si necesitás algo que Delphi te provee, usalo. Si necesitás algo que Delphi te provee a medias, usá un componente de terceros. Supongo que al menos un miembro del foro coincidirá conmigo, es cuestión de usabilidad y eficacia. Saludos. |
#17
|
||||
|
||||
Cita:
Así que, amigo Efren2006, si no tenés los suficientes escrúpulos como para programar como es debido, pues entonces podés considerar mi solución. Ahora, si por otro lado querés hacer algo como corresponde, pues usá el DataModule. Ahí está. ¿Tamos contentos ahora? ![]() |
#18
|
|||
|
|||
YO sigo contento con que aportes soluciones adicionales, así todos conocemos componentes nuevos.
Todos los días se aprende algo, es un lema necesario. Lord Delfos, yo no creo que hayas estado equivocado. Acá compartimos y aprendemos. Vos compartiste, entonces no te equivocaste ![]() Es mi opinión, no se enojen. Saludos! |
#19
|
|||
|
|||
Gracias a todos por sus opiniones.
El problema es ya tengo un proyecto de 12 modulos y cada modulo tiene miimo de 10 a 20 Formularios, todos Heredan de Formularios Bases, el tener que pasar todo a Data Module, esto seria para mi laboralmente un SUICIDIO, me atrasaria en la entrega que tengo pendiente. Yo uso el Data modulo para ciertas herramientas que desarrolle, pero el problema de ello adicionalemente al trabajo de pasar todo, es el siguiente; a la hora de diseño no hay problema porque con solo colocar en las USES el DataModule correspondiente, alli vamos bien, el problema seria su Creacion cada vez que se levante el formulario, tedria que hacer una especie de Funcion o Herramienta que cree dicho dataModule cada vez que se genere el Formulario... Buenoooo mi error de ser uno de estos programadores ortodoxos que viene de (Cobol, GWBAsic,FoxBase, FOXPRO 2.6 DOS... jajajajaj ) de hacer las cosas como se me ocurren, te pasa factura ya cuado el daño esta hecho, por eso queria saber si existia algo que fuese mas directo. Pero creo en un opinion muy personal, que la opcion que plantea .Net de colocarlos aparte no es una mala opcion, es mas yo estube haciendo pruebas con Delphi .net y tambien lo hace. |
#20
|
|||
|
|||
Cita:
Si dejás que Delphi se encargue de generarlo al inicio, no tenés más que usarlo. Pero siempre depende de cómo vos te sientas más cómodo. Saludos! |
![]() |
|
|
![]() |
||||
Tema | Autor | Foro | Respuestas | Último mensaje |
El programa se queda "colgado" mientras copia y luego "despierta" | NeWsP | OOP | 5 | 10-03-2010 22:05:40 |
¿Que opinion tienen del "Cloud Computing"? | xander | Debates | 3 | 29-10-2008 15:05:12 |
Instar componentes diferentes que utilizan "iguales" unidades | raf.rsr | Varios | 0 | 25-06-2008 14:22:50 |
Sobre componentes del tipo "TChart" o similares, preguntas varias | dec | Gráficos | 2 | 22-11-2007 13:50:47 |
Necesito llamar a métodos de clases "hija" desde su clase "padre" | Flecha | OOP | 17 | 20-04-2007 00:03:53 |
![]() |
|