FTP | CCD | Buscar | Trucos | Trabajo | Foros |
|
Registrarse | FAQ | Miembros | Calendario | Guía de estilo | Temas de Hoy |
|
Herramientas | Buscar en Tema | Desplegado |
|
#1
|
|||
|
|||
De hecho, yo estoy de acuerdo con ambos. En lo particular casi nunca hago ediciones en el DBGrid, podría decir que también los uso de sólo lectura. Es sólo que me parecía un poco descabellado desaconsejarlo.
Ahora, realmente sería interesante debatir más al respecto. Por ejemplo, leo Cita:
Lo que sí creo, es que las posibilidades de edición son mucho más amplias con otros controles, y eso puede redundar en beneficio del usuario. Bye |
#2
|
||||
|
||||
De nuevo, de acuerdo.
Debatamos : Cada uno tiene su forma de programar. Personalmente hago muchísimas comprobaciones por cada campo de edición, no todas al final. Cambio algunas ediciones 'sobre la marcha' según el valor de determinados campos. Habrá otras muchas personas que prefieran hacer las comprobaciones al final, en el evento BeforePost o de otras maneras. Perfecto. Mi caso no es así. Otra pregunta que lanzo ahora yo, a lo mejor tengo conceptos equivocados .... La 'normalización' de mi base de datos es muy amplia, es decir, utilizo muchísimas tablas diferentes enlazadas por claves comunes. Por lo tanto, el 99% de mis Select's son con join's. Me equivoco, o no sería posible actualizar dos tablas diferentes enlazadas por un Select ... join en un único grid ? Hay miles de formas de programar. Cada cual elige la que más le gusta y más cómoda le resulte. Y por supuesto que es la facilidad de manejo para el usuario final la que debe de prevalecer en cada caso sin duda alguna. Y es por ello, que me decidí a utilizar los DBGrid sólo para mostrar datos
__________________
Piensa siempre en positivo ! |
#3
|
|||
|
|||
Esto se pone bueno
Cita:
Cita:
Bye |
#4
|
||||
|
||||
Ok, vayamos sacando algunas conclusiones, estamos de acuerdo en dos cosas:
Los registros muy grandes no se deben editar en un grid, al igual que las inserciones de las fichas de empleados y asi Los grid serian como para una especie de automatizacion del trabajo del transcriptor, cuando hay que modificar varios registros a la vez. En este caso no importa que tan grande sea, es necesario un dbgrid. Con respecto a los problemas de las validaciones siempre hay alternativas que en un dbgrid se pueden ejecutar todos los eventos que lograriamos en un control ordinario.
__________________
...Yo naci en esta ribera del arauca vibr@d0r Soy hermano de la espuma, de la garza, de la rosa y del sol... Viva Venezuela |
#5
|
|||
|
|||
Estoy de acuerdo con eduarcol en que la edicion debe ser sencilla para el usuario, ademas que entre mas facil es mas eficiente un usuario, tambien hay que tomar en cuenta que tipo de usuario final utilizara el proyecto (algo muy importante!!), entre mas facil para un usuario final mayor productividad y eficiencia.
En mi opinion es mas facil editar campos de tipo edit que un dbgrid, ya que al usuario se le hace mas practico ver los campos ordenados que en un renglon, ademas que evitamos que cambien o modifique otro renglon. Saludos |
|
|
Temas Similares | ||||
Tema | Autor | Foro | Respuestas | Último mensaje |
Detectar evento cambio de foco | pborges36 | OOP | 28 | 26-05-2014 03:34:48 |
F9 - cambio de foco en pestaña | roman | La Taberna | 15 | 04-10-2006 08:46:03 |
Cambio al hacer foco con el mouse | c748a | OOP | 14 | 08-08-2005 17:31:35 |
Capturar El Evento Del Cambio De Foco En Un Form | murci | API de Windows | 11 | 21-01-2004 09:39:13 |
Foco de un edit | iriber | Varios | 6 | 26-11-2003 10:27:17 |
|