Access - refrescar valor del combo en formulario principal desde formulario de modificaciones tipo "modal"

Tengo un combo "vivienda" o domicilio en un formulario principal [F_alumnos] que despliega listado con vista de 4 columnas con los datos completos de la vivienda -id oculto, nombre calle, nro, dto, localidad- las 3 ultimas de las cuales se muestran automaticamente en cuadros de texto contiguos una vez seleccionada la opción de la lista. El dato que queda en el campo con la flecha es el nombre de la calle. A su vez, en ese campo si realizo un doble click me abre el formulario donde se cargan los datos completos de vivienda [F_vivienda_activa] que entre otros están los que forman las columnas antes mencionadas, pero hay otros más. Cuando abro ese formulario, que se muestra en modo dialogo o modal, y cambio alguno de los datos que están en los cuadros de texto no hay problema y se actualizan al instante en la vista del formulario principal; pero cuando quiero cambiar el nombre de una calle, que es el dato que queda en el campo combo, no actualiza inmediatamente sino cuando en formulario principal voy a siguiente registro y vuelvo hacia atrás. ¿Cómo podría producir ese refresh del nombre de calle en formulario principal desde el formulario abierto en modal donde se cargan los datos del combo domicilio? PD: si ese formulario lo abro en modo normal el cambio o la actualización sí se realizan completamente.

Se llegaría antes al éxito final si se aportasen datos consistentes (que hice ==>> que obtengo), los problemas tener varias soluciones y solo una de ellas suele ser la ideal.

Cuando los datos se obtienen en base a campos calculados (el caso de referenciar las columnas de los combos) su actualización requiere regenerar los datos, los calculados requerirán el evento del combo que los asigna (exige que el evento se le modifique de 'privado a publico para utilizarlo desde otro formulario sea este emergente o no emergente), las alternativas pueden ir desde recargar el formulario a actualizar (recalcular, reasignar) los datos dependientes.

En Access hay varios tipos de actualización:
Requery (recarga los datos del origen)
Recalc (efectúa nuevamente el calculo que da lugar al resultado y es menos oneroso en recursos que 'Requery' a nivel de formulario)
Repaint (refresca la imagen o el dato en la pantalla)

combox "vivienda" de formulario principal [F_ALUMNOS] contiene visibles en la lista desplegable 4 datos por registro. nombre_calle, nro_callle, dto, localidad. Estos últimos tres datos se muestran automaticamente mediante cuadros de texto contiguos al combox. Al hacer un doble click sobre el combox abre fomulario [F_vivienda_activa] que sería la vivienda correspondiente al registro presente del formulario principal, la carga de nuevas viviendas se hace por botón comando aparte que abre el mismo formulario pero en nuevo registro. Ese formulario contiene los campos id vivienda; dom_calle; número; dto; localidad y otros que no forman parte del combox.
Private Sub vivienda_DblClick(Cancel As Integer)
DoCmd.OpenForm "F_VIVIENDA_ACTIVA", , , "id_vivienda=" & vivienda.Value, , acDialog
End Sub
Cuando hago el doble click es para hacer modificaciones sobre ese registro del estudiante actual en lo que respecta a vivienda o domicilio, por ej si el domicilio estaba con datos erróneos, pero conservando el mismo id vivienda. Con una macro en evento al cerrar del formulario modal, "actualizar registro"; si hago modificaciones me actualiza al instante todos los campos que estan en cuadros contiguos al combox del formulario principal y que son las columnas del mismo arriba nombradas, la única que no actualiza o refresca es la del nombre de la calle que queda visible en el combox.
Intente llamar al formulario principal desde campo nom_calle de formulario vivienda con el evento después de actualizar o desde el mismo formulario F_vivienda_activa en el evento al cerrar con el siguiente código:
Public Sub Form_AfterUpdate()
Forms.[F_ALUMNOS].[vivienda].Requery o Refresh o Repaint
End Sub
(pero no funciona de ningun modo, error 438)

Cuando se abre un formulario (con origen de datos sea consulta o tabla) se crea de forma automática una copia fiel de los datos del momento (asume una foto como símil).

Esa misma 'foto' la obtienen todos los formularios al abrirse que utilicen esa tabla/consulta (los formularios NO tienen datos, los manipulan, los datos están en las tablas y las combinaciones entre tablas se generan mediante consultas) en definitiva: cada vez que se abre un formulario obtiene una copia fiel de los datos de su origen de datos en ese momento.

Si manipulamos (embellecemos cambiamos borramos...) los datos del registro activo en el formulario, se actualizan en el propio formulario y al salir del registro sea para ir a otro o para crear uno nuevo se ejecuta el evento del formulario BeforeUpdate que se encarga de sincronizar (actualizar/trasladar) su origen de datos (tabla consulta) con los cambios.

Esos cambios NO se reflejan de forma instantánea en las 'fotos' del resto de formularios que los estén utilizando, para que las otras 'fotos' reflejen los cambios han de volver a cargar el origen de datos.

Esto es hay una 'foto' en el formulario [F_ALUMNOS] y otra 'foto' modificada o no en el formulario [F_VIVIENDA_ACTIVA] si en el formulario [F_VIVIENDA_ACTIVA] le pintamos un bigote al sujeto de la foto, esta modificación no se reflejara en el origen de datos (tabla/consulta) mientras no se guarde el registro, esto es, mientras no se guarden los cambios, una recarga de los datos de [F_ALUMNOS] no podra ver lo bien o mal que le queda el bigote al sujeto.

Para que en [F_ALUMNOS] se presenten los cambios mas recientes (la nueva foto con el mostacho), hay que guardar los cambios generados en [F_VIVIENDA_ACTIVA], recargar los datos en [F_ALUMNOS] y rehacer las dependencias (las dependencias son el resto de datos basados en el combo).

Normalmente cuando se cambia de Item en el combo, lo hace el usuario y las interactuaciones del usuario disparan los eventos qie cargan en los cuadros de texto auxiliares las columnas ocultas del combo (es lo correcto), pero .... si el cambio de Item del combo NO lo hace el usuario con el teclado/ratón (se hace desde VBA o Macro) NO se disparan los eventos y es el programador el que tendrá que actualizar TODAS las dependencias si fuera el caso.

Se puede hacer de varias formas, desde el propio formulario no hay problema, podemos forzar el evento simplemente 'llamandolo' (Los eventos son Private, esto es: solo validos en y para el formulario, para que desde otro formulario [por ejemplo [F_VIVIENDA_ACTIVA]) se pueda forzar el evento, hay que cambiar su declaración de Private ==>> Public.

Un combo [Cbo_1] su evento 'después de actualizar se declara así:

Para forzarlo (utilizarlo sin que el usuario interactúe con el objeto) se hace así:

Pero si queremos 'utilizarlo' desde [F_VIVIENDA_ACTIVA] (un formulario que es independiente aunque compartan datos 'fotos') necesitaríamos cambiar la declaración del evento así:


Funcionará, pero atención si hay un [Cbo_1] en [F_ALUMNOS] y otro en [F_VIVIENDA_ACTIVA] en el primero no pasa nada (sea public o private le es indiferente) pero si lo utilizamos en [F_VIVIENDA_ACTIVA] tenemos un problema hay dos subfunciones que tienen el mismo nombre y puede pasar cualquier cosa.

Lo mas 'seguro' es actualizar los datos que se modifican (el combo y sus dependientes) y los pasos ya se han descrito (sea en este foro o en 'otro'), guardar los cambios actualizar el combo y (se desconoce como se están actualizando ahora) actualizar las dependencias (lo que haría el evento natural), tras ello ya se puede cerrar el emergente y regresar al formulario [F_ALUMNOS] con todo en su correspondiente lugar.

El problema que tiene 'Requery' es que recarga los datos de origen y se suele perder el registro activo (suele abrir en el primero) por lo que hay que recargar el combo, seleccionar el item (la referencia es el Id del registro en el emergente) y tras ello actualizar los cuadros de texto dependientes para que muestren los datos asociados y aqui entra lo que ya este programado y que a momento actual se desconoce y que puede presentar alguna incompatibilidad.

A lo salvaje:
Abre el emergente y cierra [F_ALUMNOS] (guarda en una variable el registro activo, su ID), pinta bigote y gafas en el registro, en el evento close de [F_VIVIENDA_ACTIVA] abre [F_ALUMNOS] y desplázate al ID guardado ... Fin (no será profesional, pero funciona perfectamente)

gracias por el esfuerzo empeñado en que pueda comprender la lógica de lo interrogado, no logro interpretar la forma en que debo codificar eso. En cuanto a ir a lo salvaje digamos que si F_vivienda_activa lo abro desde el doble click pero en modo acNormal la modificaciones se visualizan todas en el F_Alumnos una vez que cierro aquel formulario en cuestión. O sea la única que no impactaba en formulario F_Alumnos desde el modo emergente acDialog de F_vivienda_activa era la del "nombre de la calle" concretamente, los cuadros de texto que son las otras columnas del combobox y se muestran contiguas al mismo sí cambiaban al instante (eso es raro).
En modo normal no hay problemas, se abre F_vivienda, se realizan modificaciones, se cierra el formulario y todos los cambios se visualizan en F_alumnos; sólo que me había interesado intentar lograrlo desde F_vivienda_activa en modo acDialog ya que visualmente es más prolijo, y nada por saberlo ya que vengo encontrando dificultades en las acciones que conllevan llamar desde un formulario emergente a objetos de otro formulario, bueno acá es que dos formularios actualicen valores de la tabla en simultaneo.

Te he informado de la causa del problema en el foro en que se inicio la 'interrogación', rediseña el formulario y que cada campo y dato se muestre siempre 'desde el mismo sitio' y solo una vez.

Nota_
El 'método salvaje' funcionara siempre porque cumple con todas las secuencias y en su orden correcto.==> Abrir ===> Manipular ==>> cerrar y después a otro formulario a repetir la secuencia.

Sí, ahí comprendí que hay problemas cuando selecciono una misma calle. ¿Para no duplicar datos no debiera convertir en llave principal todos los campos de domicilio? al menos id, calle, nro de calle y dto? La idea de hacer un combobox con domicilio era justamente para no duplicar ese dato ya que algunos estudiantes son hermanos o familiares que comparten la misma dirección. Entonces en tabla estudiantes quedaban asignados a un nro de vivienda determinado que tiene una dirección determinada. ¿Cómo podría lograr eso? si uso varias claves principales no me permite entonces la relación de ambas tablas por vivienda id. ¿En ese caso hay que configurar una tabla intermedia? (respondí por acá porque el otro foro no me permitía ya)

Te he dejado en el otro foro una respuesta.

Nota: cuanto mas diáfano y claro quede lo que se espera de cada formulario (su funcionalidad) mas seguridad en el tratamiento de los datos se obtendrá, no seria la primera vez que para currar un catarro se aplica una guillotina y después ... pasa lo que pasa

Emiliano si quiere envíeme la base de datos comprimida en RAR a [email protected] y trato de colaborarle, con esto nos evitamos tanta "pedagogía" que puede confundirlo.