Conocer origen del foco

[rgstuamigo]

Empezado por sur-se

Hola. Gracias por la respuesta, pero no tiene nada que ver con el TabStop. Si yo pongo el TabStop a false, no entra en los saltos de la tabulación, pero si podría con el ratón entrar en el campo y eso es lo que no quiero.
Básicamente es más parecido a la propiedad enabled, de forma que si deshabilito el campo con esa propiedad, ya no me deja entrar.
El tema está en que no puedo utilizar la propiedad Enabled porque me salta el campo siguiente. Te pongo un ejemplo y quizas puedas darme una solución mejor:
- Pongo tres edits en pantalla en secuencia con el TabStop a true.
- El segundo edit lo pongo enabled:=false
- En el primer edit, programo el evento OnExit de forma que si el valor del text vale, por ejemplo, "S", entonces que habilite el segundo edit, y si no que se quede deshabilitado.
- Ejecuta la aplicación y ponte en el primer edit. Escribe "S" y luego dale al tabulador. En lugar de irse al segundo edit, que he habilitado en el onexit al comprobar el valor del campo, se va al tercer edit, cuando el segundo está habilitado, pero se lo salta.
Este es el problema que quiero solucionar. A ver si me puedes dar una solución mejor. Lo que yo he hecho es poner una propiedad "Accesible" que se pone a true o false, y en el DoEnter si la propiedad es false, entonces mando el foco al siguiente campo con el PostMessage. El único problema que tiene esta solución es que si voy para atrás (shift+tab) cuando llego a ese campo no accesible, como no se si iba hacia adelante o hacia atrás, no se si debo ejecutar el PostMessage con 0 o con 1 como parámetro para ir adelante o atrás. Y ese era el objeto de la pregunta.
Un saludo

Bueno..talves no has configurado bien la propiedad TabOrder de tus edits por eso se salta del primero hacia el tercero, dicha propiedad indica el orden en que los controles van a recibir el foco, el que tenga un tabOrder=0 será el primero, el que tenga TabOrder=1 sera segundo y asi sucesivamente;
Si te das cuenta con eso no necesitas codificar nada en los eventos OnExit o OnEnter.
Saludos...

[sur-se]

Hola.
No es eso. El taborder está bien. Si reproduces el ejemplo verás que no va por ahí la consulta.
A ver, el tema es el siguiente:
- A partir del valor de un campo edit, se trata de habilitar o deshabilitar el siguiente edit en la secuencia.
- Si este primer edit tiene un valor, por ejemplo, "S" entonces se habilita el segundo edit, pero si no permanece deshabilitado.
- El problema es que al comprobar el valor en el OnExit, y habilitar el segundo edit, este no recibe el foco, a pesar de estar habilitado.

Un saludo.

[rgstuamigo]

Empezado por sur-se

Hola.
No es eso. El taborder está bien. Si reproduces el ejemplo verás que no va por ahí la consulta.
A ver, el tema es el siguiente:
- A partir del valor de un campo edit, se trata de habilitar o deshabilitar el siguiente edit en la secuencia.
- Si este primer edit tiene un valor, por ejemplo, "S" entonces se habilita el segundo edit, pero si no permanece deshabilitado.
- El problema es que al comprobar el valor en el OnExit, y habilitar el segundo edit, este no recibe el foco, a pesar de estar habilitado.

Un saludo.

Ahora entiendo tu problema ..un poco mejor.
Lo que puedes hacer es no usar el evento OnExit de tu primer Edit sino mas bien el evento OnChange del primer Edit y colocar (segun lo que mencionas) éste codigo:

Código Delphi [-]
procedure TForm1.Edit1Change(Sender: TObject);
begin
if Edit1.Text='S' then
Edit2.Enabled:=True
else Edit2.Enabled:=False;
end;

.
Con eso ya solucionas tu problema.
Saludos...

[sur-se]

Hola. Efectivamente podría hacerse así, pero este es un ejemplo muy simplificado del problema.
La cuestión es que el valor del campo "edit1" se debe comprobar con una consulta a una base de datos. Por eso se hace la comprobación al salir, y entonces se decide, en función del valor del edit1 si se debe habilitar y se puede escribir en el edit2 o no.

Si lo pongo en el onchange, entonces estaría lanzando muchas consultas SQL inútiles a la base de datos.
No es la solución.

[rgstuamigo]

Entiendo tu dilema pero siempre hay algo que se puede hacer, lo bueno de delphi es que te brinda muchas posibilidades de resolver los problemas,pero hay que ser conciente de no aferrarse a resolver los problemas con una sola alternativa,hay que ver otras tambien.Lo que trato de decirte es que entonces puedes hacer una combinación de eventos, es decir usar ambos eventos del primer edit tanto el OnChange, y como el OnExit; el evento OnChange lo utilizas para habilitar o deshabilitar el edit2 y el evento OnExit para hacer(según dices)tu consulta a tu base de Datos..
Bueno es solo una sugerencia que te puedo hacer.
Saludos.. y ojalá te sea de utilidad.

[[Al González]]

Empezado por rgstuamigo

...usar ambos eventos del primer edit tanto el OnChange, y como el OnExit; el evento OnChange lo utilizas para habilitar o deshabilitar el edit2 y el evento OnExit para hacer(según dices)tu consulta a tu base de Datos...

El problema con eso es que, según se infiere, sur-se necesita realizar la consulta para determinar si el otro cuadro de texto debe estar disponible o no.

sur-se, te recomiendo compilar tu aplicación con la opción Use debug DCUs y colocar un punto de ruptura dentro del evento OnExit. Entonces ejecútala haciendo que se detenga en ese punto y luego abre la ventana de pila de llamadas (Call Stack) del depurador.

Ahí observarás el camino que siguió el programa desde que se disparó el mensaje wm_NextDlgCtl. Varios de los métodos ahí listados —y también algunos de los que éstos llaman— son de tipo virtual y otros de tipo mensaje, lo cual significa que pueden ser redefinidos (reescritos), algunos en tu clase formulario y otros quizá en la clase de componente que has creado.

Hay muchas posibilidades de conseguir la tabulación de captura que deseas redefiniendo alguno de esos métodos.

Saludos.

Al González.