Access - evento gotfocus no se ejecuta tras evento lostfocus

Hola a todos,

Cuento primero lo que pretendo hacer, luego cómo lo pretendía hacer y luego mi problema.

Lo que pretendo hacer:

Tengo un formulario continuo donde quiero comprobar si ha habido alguna modificación en el valor de un cuadro de texto del formulario.

Cómo lo pretendía hacer:

1. Asigno al cuadro de texto un evento de GOTFOCUS para que cuando el usuario se posicione sobre él se almacene su valor en una variable public.

2. También asigno al mismo cuadro de texto un evento de LOSTFOCUS para que cuando el usuario lo abandone se compare el valor en ese instante con el valor que tenía cuando el usuario se posicionó en él (Almacenado en la variable public comentada anteriormente).

3. Comparo con un IF los dos valores, el menos reciente y el actual. Si son diferentes, ha habido alguna modificación y se ejecuta un determinado proceso que no viene al caso. Si son iguales, no ha habido ninguna modificación y no se realiza nada.

Mi problema:

Si el usuario (una vez que se ha posicionado en el cuadro de texto que contiene los eventos GOTFOCUS y LOSTFOCUS) se posiciona en otro cuadro de texto, el procedimiento funciona bien. En cambio, si el usuario se posiciona en otro registro del mismo cuadro de texto (recuerdo que es un formulario continuo) sólo se ejecuta el evento LOSTFOCUS y NO el GOTFOCUS+LOSTFOCUS del nuevo registro.

¿A alguien se le ocurre alguna solución? Sólo se me ocurre establecer un SETFOCUS en cualquier otro cuadro de texto al final del procedimiento Sub LOSTFOCUS pero no me gusta porque puede confundir al usuario. (El usuario vería que cuando baja de registro en un mismo "campo" representado por cuadro de texto, el cursor se posicionaría en otro lado)

Muchas gracias de antemano por vuestro tiempo y disculpad la extensión del mensaje, quería explicarme lo mejor posible.

Hola, no me queda claro lo del posicionamiento fuera de los dos campos en los que si se tiene que ejecutar al tener el foco y al perder el foco, en teoría sino se afecta uno de esos campos, lo lógico es que te falle de la manera en que estas comentando, lo que se me ocurre, si entendí bien, es poner esos dos campos obligatorios y en el respectivo orden, por otro lado yo no pondría en al perder o recibir foco, sino, después de actualizar, eso te garantiza que el calculo se haga solo si en realidad escribieron datos, mientras que en el otro sistema con solo poner el mouse en ese campo comienza el proceso, aun sin tener datos lo que puede generar información errónea.

Hasta pronto.

No entiendo esa lógica de volver a entrar sin haber salido ....

Lo que se puede hacer (si se desea mantener ese código) es crear un objeto que pueda recibir el foco (puede ser un cuadro de texto de mínimo tamaño) que en cuanto reciba el foco lo devuelva al objeto que anteriormente lo tenia (a quien se lo mando), así se cumpliría el salir y volver a entrar (se puede utilizar la variable PreviousControl del objeto Screen) .

Si deseásemos un método menos invasivo, podríamos utilizar el evento 'después de actualizar' (solo se ejecutaría en caso de necesidad) y comparar el actual valor (.value) con el valor que tenia antes (.OldValue) de esa forma incluso sobraría la variable publica (no tendría objeto almacenar un dato ya almacenado y disponible)

Hola, gracias por contestar. Comprendo que sea lioso.

Tengo un formulario configurado como continuo, por lo que aunque en vista diseño aparezca un cuadro de texto, en vista formulario el usuario ve varios registros (uno debajo de otro). El problema estaba cuando el usuario, en vista formulario, se posicionaba en un registro del campo (creado por el cuadro de texto del formulario continuo) y luego en otro registro de ese mismo campo.

Tenía breakpoints en el código para verificar que salía todo bien. Lo gracioso es que probé a quitar los breakpoints para que se ejecutase de seguido y ahora funciona. Será cuestión de que al interrumpir el código cuando se ejecutaba se activaba otra ventana.

De toda formas, tu solución me parece mucho más acertada. Desconocía el .OldValue porque no llevo mucho en esto. Sabiendo que se puede rescatar el valor que tenía antes de actualizarse, como bien dices, no tengo necesidad de crear la variable public y tampoco tengo por qué crear dos eventos de salida y de entrada de foco. Con el evento de después de actualizar y el .value y .OldValue me vale para lo que quiero hacer. Gracias por tu aportación!

Pregunta relacionada con el evento que me has sugerido:Si en un formulario1 meto el evento "después de actualizar" en un cuadro_de_texto1 y, si hago cambios, mediante VBA hago que se escriba en un campo de una tabla (ajena al formulario1) donde en un formulario2 un cuadro_de_texto2 bebe de dicho valor...y a parte de todo eso tengo un evento "después de actualizar" en ese cuadro_de_texto2...¿Se me ejecutaría el evento en el cuadro_de_texto2 si no tengo el formulario2 abierto? ¿No, no?

Aclarando la duda:

Los eventos de los formularios u informes se producen cuando el usuario interactúa con ellos por ejemplo 'al hacer click', si no hay un (permítaseme la licencia) acto físico, el evento no se produce.

Pero ... si aun así deseásemos 'hacer lo que hace' ese evento (sin el click físico o la interactuación), no hay que perder de vista que los eventos (generalmente sub-funciones) no son mas que código con un nombre y como tales trozos o rutinas se pueden ejecutar (lo que ahorraría el duplicarlos)

Si hacemos un click con el ratón funcionara 'normalmente' , para que lo haga a capricho del programador basta estar en un entorno en que sea accesible (normalmente son privados) y llamarlos por su nombre.

Un clásico, tenemos un botón para salir del formulario, ese botón generaría una serie de procesos en su evento click.
Creamos una rutina que tras hacer una serie de modificaciones debería dar por finalizado el proceso (repetir lo que hace el botón de salir) y para no repetir lo que ya existe bastaría 'llamar a ese evento', si al botón le 'llamamos 'Btn_Salir' su evento seria:

Private Sub Btn_Salir_Click ()

Para ejecutarlo a voluntad (y sin hacer 'esfuerzo físico') bastaría un:
BTn_Salir_Click

Y aquí se acaba el misterio

Muchas gracias por tu explicación. Es como me imaginaba y lo has aclarado perfectamente.

Un saludo!