Cambio de foco a otro edit
 

Saludos.

Tengo la siguiente duda, estoy desarrollando una aplicacion donde tengo varios campos (edit.text), y al cambiar el foco al siguiente campo lo tengo que hacer con el mouse ya que al cambiarlo con el tabulador cambia a otro no deseado (es decir, que no sigue la secuencia de orden que tengo ya que los tengo salteados, edit1, edit5, edit 6, edit2, etc..), ¿Como puedo cambiar a un edit que yo le indique al presionar el tabulador.

Espero que me puedan ayudar..

Utiliza la propiedad TabOrder para indicar el orden de las tabulaciones :). La tienen todos los componentes que pueden tomar foco, aunque debes de tener en cuenta que los componentes que coloques dentro de un TPanel, por ejemplo, tienen un TabOrder independiente de los que están fuera del panel.

Ok, quiza me digas que soy novat y si de hecho, jeje, tabOrden es propiedad o tengo que poner el codigo? si es codigo, podrias poner un ejemplo de como se hace?

Gracias!!!:D

Me he fijado en que eras novato :p, pero esa pregunta que haces ¿no la podrías comprobar ya mismo? Abres Delphi y miras si los edits tienen esa propiedad, y si no la encuentras, buscar en la ayuda, y si tampoco hay nada, buscar en el foros, en Google...

aquí todos hemos aprendido buscando :)

Además, ¡ya te he puesto que es una propiedad!
Salu2.

Ok, tienes razon, debo investigar, gracias por la ayuda!!

Aqui nadie nace sabiendo no te preocupes jejeje yo tambien soy un novato y eh tenido la fortuna de encopntrar en el foro gente que sabe mucho y me han ayudado mucho. jejej

bueno mira encuanto a tu duda no se si deba decirtelo jeje en realidad no es complicado solo da click izquierdo sobre la forma donde estan tus edits y ahi saldra un meno en ese menu debe decir tab Order lo seleccionas y ahi pones el orden de los edits como tu lo decees :)

y no creas que hay preguntas tontas porque no sabes si alguien tenga la misma pregunta y con tu post lo ayudes jejejej es algo que en el foro he aprendidooo :D

Gracias Yun-i!!

Es verdad que nadie nace sabiendo, pero lo que si es que debi investigar un poco mas y entender la respuesta que me dio ixMike, ya que no era nada compiclado buscar en las propiedades del edit:D, te agradesco también por tu ayuda que me ha servido de mucho ya que tambien es una buena forma de solucionarlo.

Saludos!!:)

Uan vez abierto tu formulario en Delphi, arriba en el menú 'Edit' del propio Delphi encontrarás otro Submenú que es 'Tab Order'.

Ahí podrás ordenador 'visualmente' todos los componentes que tengas en tu Form según el orden de tabulador que te interese. Una vez hayas realizado esta operación, en cada uno de tus componentes podrías comprobar la propiedad TabOrder que te han indicado para verificar el orden en que se ha colocado.

... ahora bien, es mucho más inmediato y fácil hacerlo como te indico en mi primer párrafo.

;)

Excelente respuesta gluglu!! Verlo visualmente es de mucha ayuda, he solucionado el problema con el tab order, solo tengo una duda, cuando entro a un Dbgrid y cambio con el tabulador me regresa al primer registro, ¿Habrá alguna forma de salir del dbgrid?

Saludos!!

No he entendido tu pregunta :

No sé a lo que te refieres. :confused:

Perdon por no haberme explicado bien, me refiero a que tengo un dbgrid y selecciono un registro mostrado dentro de un dbgrid por una consulta previamente hecha, cuado presiono el tabulador cambia al siguiente campo (ej, Nombre, Apellido, etc... selecciono nombre y presiono la tecla tabulador, este cambia a Apellido), mi pregunta era como puedo seleccionar un edit despues de haber seleccionado un dbgrid, es decir cambiar con el tabulador a un edit o boton. Espero que haya quedado un poco mas claro, perdon, pero no soy bueno explicando las cosas, tengo que practicar mas:D.

Gracias

En las propiedades del dbGrid hay una seccion llamada options, alli ubica la propiedad TABS y colocala en FALSE

Además de la propiedad que indica eduarcol, también te puedes fijar en la opción RowSelect, dentro de la propiedad Options del DBGrid. Este te seleccionará la línea entera en vez de cada campo por separado. Así no te irá desplazando con el tabulador por cada una de las columnas que tengas en el DBGrid.

Eso ya dependerá de tus preferencias personales. ;)

de sus preferencias y necesidades, ya que el RowSelect es de solo lectura, si necesita editar no va a poder con esa propiedad

Totalmente de acuerdo, eduarcol.

Recuerdo mis inicios en los que aprendí a través de este foro que editar directamente en el DBGrid es altamente desaconsejable ... :rolleyes:

Pero de nuevo, esa decisión la dejo al criterio de cada cual ;)

¿Por qué? :confused:

Bye

Ahora si tienes mi atencion por completo, porq piensas que no se puede aconsejar esas ediciones, si asi las tengo en todos mis sistemas y no me ha dado problema :confused:

También que especifique, por favor, en qué hilos aprendió eso. :D

Bye

Problema no tiene que dar ninguno. Simplemente creo entre otras cosas que las posibilidades de editar fuera de un DBGrid son mucho más amplias. Insisto, problema ninguno en sí mismo. Probablemente enredos díficiles de resolver dentro del propio DBGrid cuando se trata de ediciones complejas.

... voy a buscar hilos acerca de lo que digo que se desaconseja .... :o

Un hilo al respecto de nuestro gran maestro 'perdido' Roman

¡Ah! En eso estamos de acuerdo. Un DBGrid puede ser muy ineficiente para editar datos de registros con muchos campos y/o datos complejos. Pero hay también situaciones en las que un control tabular es recomendable, por ejemplo, si sólo tienes que modificar unas cuantas columnas sencillas pero debes hacerlo en varios registros (por ej: las calificaciones de los alumnos de un grupo). Si obligas al capturista a abrir una ventana modal para cada edición, se va a acordar de ti :)

Bye

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

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

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

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. :o

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.

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

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

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

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 :rolleyes:

Esto se pone bueno :)

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.

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

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.

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