Cambio de foco a otro edit

[[eduarcol]]

Con todo el respeto que Roman merece no estoy de acuerdo con esa metodologia, yo trabajo con personas que manejan gran cantidad de informacion y darle doble click a un registro para que aparezca otra ventana editar y volver a grabar cuando se trata de 300 a 500 veces al dia puede ser canson.

En el caso de vistas complejas yo lo que hago es que trabajo una tabla de memoria y luego actualizo. Las operaciones de edicion se solucionan con los eventos respectivos a nivel de Dataset, Field, Dbgrid, datasource

[odrack]

Saludos a todos, gracias por los comentarios, los sigo provando y han funcionando muy bien sus soluciones y las estoy adaptando al proyecto.

Creo que tambien hicieron varias observaciones y comentarios, a lo cual les explico un poco, no estoy editando en el bdgrid ya que solo lo utilizo para consultas y tampoco es recomendable editar en el dbgrid ya tendrias algunos errores al insertar modificar y esto se por el tipo de objeto con el que lo tienes ligado, exactamente no conosto como funciona el objeto dbgrid, pero si lo tienes ligado con un tquery no te permitira editarlo y con un table lo podras editar pero he notado que no actualiza los campos cuando agregas mas de dos registros consecutivos, tienes que actualizar para poder continuar con tu registro.


Saludos

[keyboy]

Empezado por eduarcol

yo trabajo con personas que manejan gran cantidad de informacion y darle doble click a un registro para que aparezca otra ventana editar y volver a grabar cuando se trata de 300 a 500 veces al dia puede ser canson.

A eso me refiero. Pero leyendo el hilo que mencionan, no veo que se haya desaconsejado en ningún momento el uso de DBGrids para edición. Él mismo menciona, a no ser que sea absolutamente necesario, y casos como éstos, son necesarios.

Pero, si, por el contrario, las ediciones no son demasiadas, pero sí tienes una multitud de campos, sería muy pesado para el usuario hacerlo en un DBGrid.

Bye

[[gluglu]]

Vuelvo a estar de acuerdo con las dos opiniones anteriores .

No obstante, sobre gustos no hay nada escrito. Yo, por mi propia experiencia, utilizo el DBGrid sólo para mostrar datos.

No quiero decir con ello que para editar un registro de una tabla haya que abrir una nueva ventana (modal o no). Hay otras muchas maneras. Yo utilizo otras opciones para que 'parezca' que estás editando directamente sobre el DBGrid aunque realmente no sea así. No creo que sea momento de entrar aquí en como y cuando un método u otro es mejor.

Las posibilidades de comprobación y de verificación son mucho más amplias si no editas dentro del propio Grid. Insisto, sobre gustos no hay nada escrito.

Ademas, si las consultas se van complicando, incuyen 'joins', 'subconsultas', etc, se vuelve casi imposible editar en el DBGrid directamente. Por ello decidí desde un principio como 'norma' (mía...) el editar siempre fuera del DBGrid.

Vuelvo a ser insistente .... con ello no quiero menospreciar la opinión de nadie.

[[eduarcol]]

Empezado por keyboy

A eso me refiero. Pero leyendo el hilo que mencionan, no veo que se haya desaconsejado en ningún momento el uso de DBGrids para edición. Él mismo menciona, a no ser que sea absolutamente necesario, y casos como éstos, son necesarios.

Pero, si, por el contrario, las ediciones no son demasiadas, pero sí tienes una multitud de campos, sería muy pesado para el usuario hacerlo en un DBGrid.

Bye

Precisamente, eso mismo pienso yo, el programador no debe trabajar en base a sus comodidad, debe pensar en la facilidad de uso poniendose en el lugar del usuario final, que es a fin de cuentas quien le dara el exito a su producto.

[[eduarcol]]

Empezado por gluglu

Vuelvo a estar de acuerdo con las dos opiniones anteriores .

No obstante, sobre gustos no hay nada escrito. Yo, por mi propia experiencia, utilizo el DBGrid sólo para mostrar datos.

No quiero decir con ello que para editar un registro de una tabla haya que abrir una nueva ventana (modal o no). Hay otras muchas maneras. Yo utilizo otras opciones para que 'parezca' que estás editando directamente sobre el DBGrid aunque realmente no sea así. No creo que sea momento de entrar aquí en como y cuando un método u otro es mejor.

Las posibilidades de comprobación y de verificación son mucho más amplias si no editas dentro del propio Grid. Insisto, sobre gustos no hay nada escrito.

Ademas, si las consultas se van complicando, incuyen 'joins', 'subconsultas', etc, se vuelve casi imposible editar en el DBGrid directamente. Por ello decidí desde un principio como 'norma' (mía...) el editar siempre fuera del DBGrid.

Vuelvo a ser insistente .... con ello no quiero menospreciar la opinión de nadie.

Es un debate sano, es normal que estemos en desacuerdo, es mas si quieres abrimos un hilo en debate para solucionar el asunto , sigo pensando que es mas complicado configurar los controles externos al dbgrid como lo haces que configurar el dbgrid para que funcione correctamente.

[keyboy]

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

Empezado por gluglu

Las posibilidades de comprobación y de verificación son mucho más amplias si no editas dentro del propio Grid

y me sorprendo. Yo normalmente verifico lo que haya que verificar como un todo al final de la edición. Y, de hecho, la validación no debería depender de la forma en que se editen los datos, para ello está, por ejemplo, el evento BeforePost del DataSet.

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

[[gluglu]]

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

[keyboy]

Esto se pone bueno

Empezado por gluglu

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í.

Creo que aquí hay involucradas dos cosas distintas. Cuando hablas de cambiar algunos campos dependiendo del valor de otros, estás ayudando al usuario en la edición para quitarle responsabilidad en cuanto a satisfacer las reglas de negocio. Y está muy bien. Pero un registro, en tanto entidad de tu sistema, debe validarse independientemente de las formas y métodos que se usen para introducir los datos. Esto te garantiza que, no obstante como los introduzcas, éstos satisfarán las reglas de negocio. Al tener centralizada la validación, evitas cualquier posible hueco.

Empezado por gluglu

Me equivoco, o no sería posible actualizar dos tablas diferentes enlazadas por un Select ... join en un único grid ?

Pues siempre puedes usar un componente UpdateSQL o equivalente, o un ClientDataSet. Pero en este punto recuerda que concuerdo contigo. La edición de un registro complejo, puede ser muy fastidiosa en un DBGrid. Incluso puede ser que en el DBGrid se permita editar campos sencillos, de cambio frecuente, y para campos más complejos uses otros controles. Esto es, un método híbrido.

Bye

[[eduarcol]]

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.

[odrack]

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