Access - combos anidados separados en dos formularios

Hola. Tengo 4 cuadros combinados anidados o sincronizados, que al elegir determinada opción en el primero, en el segundo, en el tercero y cuarto van apareciendo en cascada las diferentes listas de opciones correspondientes en los subsiguientes según los estipulado.Hasta ahí todo bien.
El cuadro combinado principal o 1 se halla en un formulario A y los otros tres combos se completan al entrar a un nuevo formulario B, accionando boton "abrir formulario B", el cual se abre en modo dialogo. Si tengo que completar nuevos registros pareciera funcionar todo perfecto, pero cuando por alguna equivocación tengo que cambiar una opción ya elegida en el cuadro combinado 1, al volver a ingresar al formulario B sólo el cuadro combinado 2 está en blanco o vacío; los cuadro combinados 3 y 4 mantienen las opciones elegidas anteriormente que ni siquiera pertenecen a las opciones esperadas por la nueva selección realizada en el cuadro 1 en formulario A. De todos modos, si despliego la lista en combo 2 aparecen las categorías esperadas y al seleccionar una de ellas entonces sí se blanquean los combos 3 y 4 y las listas de los mismos son las sincronizadas.
La pregunta sería como lograr que los combos 3 y 4 también se blanqueen al cambiar la opción seleccionada en combo principal 1, de modo de evitar confusión en otro usuario. Intenté llevar el id del combo 1 como "default value" al formulario B -a través de un evento en el generador de código-, para ver si se "activaba" la sincronización de los combos 3y 4, por lo que deberían vaciarse si hay opciones de lista no correspondientes a la nueva selección en el principal, pero en este caso lo que sucede es que el valor por default del combo 1 transportado al formulario B no se actualiza al modificar el combo 1 del formulario A.
Saludos gracias

Gracias por responder pero no llego a comprender por mi falta de expertise. Concentrando la solución en la primera parte, pese a estar en modo dialogo los combos están vinculandose, pero sólo se vacía el combo 2 del fomulario B, aunque las listas desplegables son las correctas. En los combos 2,3 y 4 que estan en el fomrulario B, en el evento "despues de actualizar" les fui agregando sucesivamente las capas de Me.Requery y en la respectiva consulta, a través de "datos" de hoja de propiedades, asociándolos con el generador en la fila de criterios; por lo que en el combo 1 del formulario A, siguiendo esa lógica inscribí este código en el mismo evento pero genera error (lo convertí a public pero tampoco responde).

[FOMRULARIO A] COMBO 1

Public Sub cdro_1_AfterUpdate()
Me.cdro_2 = vbNullString
Me.cdro_2.Requery
Me.cdro_3 = vbNullString
Me.cdro_3.Requery
Me.cdro_4 = vbNullString
Me.cdro_4.Requery
End Sub

[FORMULARIO B] COMBOS 2,3,4 ----- esto funciona sin el código de arriba

Private Sub cdro_2_AfterUpdate()
Me.cdro_3 = vbNullString
Me.cdro_3.Requery
Me.cdro_4 = vbNullString
Me.cdro_4.Requery
End Sub

Private Sub cdro_3_AfterUpdate()
Me.cdro_4 = vbNullString
Me.cdro_4.Requery
End Sub

No le veo muchas posibilidades a ese diseño, en principio sincronizar objetos o en particular combos no supone un problema, se puede complicar si los objetos se encuentran dispersos en zonas diferentes (por ejemplo en varios formularios).

En este caso (formularios diferentes ‘A’ y ‘B’) en los que en ‘A’ se hace la primera selección y tras él se accede a ‘B’ (en mi opinión) tiene poco sentido práctico máxime si ‘B’ se utiliza en modo dialogo, si se desea cambiar lo seleccionado en ‘A’ es imprescindible cerrar ‘B’ (que está en modo dialogo).

Yo utilizaría otro esquema:
.- Desde ‘A’ abrir ‘B.
.- En ‘B’ estarían los cuatro combos
.- Finalizado el proceso de selección se actualizaría el valor de referencia en ‘A’.

Sobre el código publicado hay un claro error conceptual:
.- ¿Quién tiene que ser ‘publico’ el que ofrece el que busca? …. (Referencias: tienda y cliente).

En ese diseño, desde ‘A’ no se puede acceder a ‘B’ porque ‘B’ solo EXISTE si está abierto y si ‘B’ está abierto en modo dialogo ya estamos en ‘B’ (sin discusión: ya no estaremos en ‘A’)

Lo correcto es que sean ‘públicos’ los elementos a compartir y es optativo que sea público o privado quien lo utiliza (solo exige ser publico si ‘quien lo utiliza’ es a su vez utilizado desde otro entorno, en su entorno por defecto es público).

Por eso funciona lo creado en ‘B’ y creo que bastaría cambiar el origen de datos del combo (no el valor) para que el combo quedase en blanco (además de vacío), cambiar el valor no cambia el contenido, solo el elemento seleccionado.

Si se desea utilizar un elemento de otro formulario, NUNCA se puede referenciar con ‘ME’:
ME = El formulario activo (en el que corre el código)

Me.cdro_1 ===>>> Forms.FormularioA.cdro_1
Me.cdro_2 ===>>> Forms.FormularioA.cdro_2 <<<<<< ------- ¿Existe?

Para acceder a ‘B’ (FormularioB) desde ‘A’ es imprescindible:
.- Que ‘FormularioB’ está abierto
.- Que el elemento sea público (‘cdro_2_AfterUpdate’ este declarado como público)

Y ya se podrá referenciar al elemento así: Forms.FormularioB.cdro_2_AfterUpdate

El (al menos: mí) desconocimiento del entorno real hace suponer que desde ‘A’ se abre ‘B’ enviándole (o referenciando) el elemento de ‘A’ para sincronizarse y que ya en ‘B’ y sincronizado, se continúe con el resto de procesos.

En ese entorno: para poder rectificar la selección original (efectuada en ‘A’) se tiene que cerrar ‘B’ (abierto en modo dialogo) y eso debería reiniciar el ciclo.
Para limpiar ‘B’ de posibles restos anteriores: en su evento OPEN o LOAD se hace la limpieza (de ser necesaria).

Tomé tu consejo de desarmar el formulario B y pasar todos los comboa juntos a formulario A. Pero el motivo de mi pregunta en el foro persiste de todos modos en ese caso también. Una vez que ya hice elecciones de categorías en los combos 1 2 3 y 4, y sin cambiar de registro se me ocurre que tuve un error y elijo otras opciones de las listas; al modificar la opción del combo 1 NO SE VACÍAN las opciones de lista de combo 3 y 4, sí la del combo 2; y así sucesivamente, al cambiar la del combo 2 se vacía la del 3 pero no la del 4. Es simplemente algo visual, no afecta lo que queda registrado en la tabla, pero no es prolijo nada más y seguro es alguna falla en la sincronizacion de los 4 combos que están vinculados pareciera de uno en uno en vez de los 4 juntos.

No fue ese mi consejo, pero la solución adoptada también es válida (suele ser la más utilizada).

La opción de abrir un formulario (y en modo emergente) se suele utilizar cuando se necesita o desea que el formulario de trabajo sea simple (no abigarrado y lleno de controles de uso poco frecuente).

Sea el método que sea: si hace de forma correcta lo que se le programa, bien hecho esta.

Un combo es una forma de presentar un conjunto de datos para elegir uno de ellos, una cosa es el contenido (su RowSource) y otra es tener uno de sus elementos seleccionado (que es cuando devuelve ese valor seleccionado), esto es:

Un combo solo devuelve un dato si ha sido seleccionado previamente, si no se le estableció una opción por defecto y no se interactuó con objeto combo (por ejemplo asociándolo a un campo del formulario que lo contiene) no devuelve nada (está vacío).

Si el combo1 activa su evento ‘después de actualizar’ es que se ha seleccionado uno de sus elementos y (en base a él) el combo2 puede recibir un subconjunto de datos (relacionados con el combo1), pero si no se le asigna un valor por defecto (por ejemplo: que tome el primer ítem) carecerá de valor.

Si hay un tercer combo (combo3) que recibe un subconjunto de datos en base al elemento seleccionado en el combo2 y este no tiene un valor asignado ¿Qué podrá presentar el combo3? y si los hubiera: el combo4, combo5,…, comboNN.

Si en medio de una interactuación con los combos (todos dependientes del primero) se cambia el elemento seleccionado en el combo1 ¿Qué debería ocurrir con los/sus combos dependientes?.
(NOTA: todos o parte de ellos ya tienen un origen de datos y un elemento seleccionado)

Si se parte de un registro nuevo:
.- Todos los combos estarán vacíos, y solo el combo1 tendrá origen de datos.

.- Al seleccionar en el combo1 uno de sus Ítems se le asigna al siguiente (combo2) el origen de datos, se le envía el foco y queda a la espera de la selección de uno de sus Ítems, y tras esa selección se repite el mismo ciclo con el combo3 y tras el combo4…. etc.

Si no es un registro nuevo:

Si tras ese ciclo se cambia el ítem seleccionado en el combo1, el combo 2 tendrá un valor asignado (ya no está vacío) lo que implicara una limpieza de sus combos dependientes, y tras ello se continua con el mismo proceso anterior (como si fuera un registro nuevo).

.- Esto se puede hacer (se debería hacer) en cualquier combo si se cambia el elemento en el seleccionado: si el siguiente tiene valor hay que limpiarlo a él y a los que lo continúen -.

Queda claro pues que tras seleccionar un Ítem en cualquier combo, los datos de los que dependen de él no valen nada (una limpieza es el paso obligatorio).

¿Exactamente que deseas obtener? …
Hay que tratar los datos en función de lo que se pretende hacer con ellos y de ello va la programación, de utilizar de forma eficiente los medios disponibles para obtener lo que se planifica como resultado.

Perfecto, yo dejaría los combos 2,3 y 4 en ese formulario B por un tema de prolijidad. Estos ya están relacionados al formulario A por el id del registro principal del mismo que lo llevo en modo default al formualrio B, el otro registro que había llevado por default pero no haría falta es la opción seleccionada en el combo 1 porque creí que de ese modo se actualizarían el resto de los combos limpiándose, pero ene ste caso ni siquiera se actualizaba el default al modificar el combo 1.
En resumen, lo único que quisiera es que si la modificación se realiza en el mismo registro ("si no es un registro nuevo" en tu explicación detallada anterior), los combos 3 y 4 se limpien al cambiar la opcion del combo 1 -la del combo 2 se llega a limpiar no sé porque-. Sólo hice la prueba de colocar todos los combos en el mismo formulario para ver si así se limpiaban pero pasaba lo mismo, al modificar el combo1 se limpiaba el combo 2 y no así el 3 y 4 que quedaban en la selección anterior (aunque las listas sí tiene los valores correspondientes al cambio).
De todos modos, al seleccionar una opción de la lista del combo 2, el 3 y 4 ya se limpian. No entiendo porque esa misma limpieza automática no se realiza desde la modificación en el combo 1, ¿hay algún evento de actualización que me falta generar en ese combo entonces y que sí funciona desde el combo 2 o se hace en el formulario B?.
Gracias

El combo2 se 'limpia' porque se le asigna un nuevo origen de datos al cambiar el Item del combo1, pero eso no activa el evento que activa la limpieza en los combos dependientes (lo hace al activar el evento)

Supongo (no me apercibí de que se publicase), que se utiliza un evento en la apertura del formulario_B para asignarle a su combo2 un origen de datos relacionado con el combo1.

¿Porqué no utilizar el mismo evento para asignarle un falso origen de datos a los combos 3 y 4?, una cadena de texto vacía es suficiente, ya les llegara el momento de recibir un origen de datos adecuado.

Si los combos 3 y 4 presentan datos anteriores al 'reabrir' el formulario_B, es porque existen en el origen de datos del formulario, (al salir del formulario se guarda el registro).

Limpiarlos en un evento de apertura del formulario_B presumo que será mas sencillo que borrar y volver a crear el registro subyacente.
En base a las dos posibilidades:

.- Si es un registro nuevo, todos los combos 'nacerán en blanco', por lo que volver a darles el valor que ya tienen no les dañara

.- Si se vuelve a entrar (por la modificación en el combo1), los datos que tengan (producto de la selección que se desea rectificar) no son validos (pero si tan molestos como ya inútiles).

Espero que ese añadido hará que se comporte como se desea

Hola, ¿No es posible con algún condicional IF? Que consista en por ej "Si al abrir Formulario B el combo 2 está nulo o vacío, entonces combo 3 y 4 también vacíos". Porque si se ordena limpiarlos siempre al abrir no se podría utilizar la apertura del formulario B para visualizar ya que cada vez que lo abra se limpiarían los combos, en cambio si está atada la limpieza a q el combo 2 este vacío eso asegura que se trata de una modificacion de valores en el mismo registro. ¿Podrías ayudarme a escribir ese código si crees que es correcta la propuesta ? Gracias

Se puede hacer todo desde cero ignorando todo el esfuerzo en crear lo actual, pero es una mala idea porque puede generar conflictos en futuras ampliaciones.

Lo correcto es adaptar la solución continuando con la línea de diseño actual y para ello solo se precisa conocer lo que ya esta creado.

No veo que problema supone cambiar unos valores que no tienen sentido al cambiar la referencia (que continua siendo el combo1 del formulario_A).

Esa referencia se mantiene, solo se modificara el contenido del formulario_B (sus datos) y ese contenido ya no es coherente con la nueva referencia.

Creo que no se tiene claro como se procesa la información mediate combos y tampoco como y cuando funcionan los eventos de los objetos.

Plantéate una simple cuestión:
Acabas de finalizar un trabajo para el que hay que lavarse las manos pero has de rehacerlo (esto es: repetirlo):
¿Para que analizar si necesitas lavarte las manos de nuevo? cuando tardas menos en volver a lavarlas y eso garantiza que estarán limpias (o mas limpias).

si, la idea es mantener el diseño actual. Lo que no sé, y por eso pregunto en este foro, es como hacer que los combos 2 y 3 se limpien en función de los cambios ocurridos en el combo 1 del formulario A mientras se actúa en el mismo registro. Si puedes traducirme en algún ejemplo en código en base a los descripto hasta aqui.

Creo que aún se desconoce el método empleado para 'sincronizar' el combo2 con el combo1.

Es un procedimiento (código) que aportaría lo necesario para conocer el entorno, el evento y la metodología utilizada de las varias que se pueden aplicar.

Lo que se puede utilizar ya está comentado en anteriores post de este mismo hilo y para poder aplicar alguno hay que decidir de entre ellos cual, como y (conocido el entorno) donde.

esta sincronizado por medio de un default value del id principal del registro del formulario A, id_intervencion, el cual se lleva al formulario B en evento al cargar
F_CARGA_INTERVENCION_EOE es el formulario A que contiene el combo 1
F_MOTIVOS_CATEGORIAS_DATOS es el formulario B que se abre desde el A y tiene los combos asociados 2,3 y 4

Private Sub Form_Load()
Id_intervencion.DefaultValue = Forms![F_CARGA_INTERVENCION_EOE]!Id_intervencion
End Sub

por otro lado en el origen de la fila del combo 2, en la consulta de hoja de propiedades, se asocia a la llave externa (id_combo1) de la tabla que trae los valores de dicho combo mediante el generador en la fila criterios: Formularios]![F_CARGA_INTERVENCION_EOE]![cdro_motivo_intervencion] >>> este es el combo 1

Del mismo modo esta hecho con los otros combos del combo 3 al 2 y del 4 al 3 más los eventos despues de actualizar

Private Sub cdro_2_AfterUpdate()
Me.cdro_3 = vbNullString
Me.cdro_3.Requery
Me.cdro_4 = vbNullString
Me.cdro_4.Requery
End Sub

Private Sub cdro_3_AfterUpdate()
Me.cdro_4 = vbNullString
Me.cdro_4.Requery
End Sub

Pregunta:
¿La relación entre los orígenes de datos de los formularios es uno-uno o uno-varios (1-1) o (1-N).?

Si la relación entre ambos es (1-1)
¿Supondría un problema que todos los combos perteneciesen al origen de datos del FormularioA?

(-Que todos los datos estén en la misma tabla no impide utilizar varios formularios para utilizar en cada uno de ellos diferentes subconjuntos-)

Sí, la relacion entre los formularios es 1 a 1. Pero referenciando ese codigo de evento despues de actualizar del combo 1 con formulario B no funcionaría? no encuentro el modo en que me lea los requery en referencia al fomulario B. No es mediante Forms!nombre de formulario! nombre de control.requery ???

[FOMRULARIO A] COMBO 1

Public Sub cdro_1_AfterUpdate()
Me.cdro_2 = vbNullString
Me.cdro_2.Requery
Me.cdro_3 = vbNullString
Me.cdro_3.Requery
Me.cdro_4 = vbNullString
Me.cdro_4.Requery
End Sub

Primero las dudas:
Para referenciar a un objeto que NO pertenece al formulario en que corre el código, la referencia deberá ser absoluta.

En aras de ser fiel y concreto, utilizare los que he deducido que son los 'nombres reales' en la aplicación (por favor, si no lo son: corrígelos)
FormularioA : [F_CARGA_INTERVENCION_EOE]
FormularioB: [F_MOTIVOS_CATEGORIAS_DATOS]
Los combos: [cdro_1], [cdro_2], [cdro_3],[cdro_4]

Referenciando a [cdro_1..4] desde [F_CARGA_INTERVENCION_EOE]
Me.[cdro_1] -- referencia relativa --
Forms.[F_MOTIVOS_CATEGORIAS_DATOS].[cdro_2] -- referencia absoluta --
Forms.[F_MOTIVOS_CATEGORIAS_DATOS].[cdro_3] -- referencia absoluta --
Forms.[F_MOTIVOS_CATEGORIAS_DATOS].[cdro_4] -- referencia absoluta --

Referenciando a [cdro_1..4] desde [F_MOTIVOS_CATEGORIAS_DATOS]
Forms.[F_CARGA_INTERVENCION_EOE].[cdro_1] -- referencia absoluta --
Me.[cdro_2] -- referencia relativa --
Me.[cdro_3] -- referencia relativa --
Me.[cdro_4] -- referencia relativa --

Para poder acceder a un objeto (o a sus eventos) desde otro formulario tiene que ser declarado como PUBLICO, y utilizar su ruta absoluta
Si no se accede a un objeto desde otro formulario NO necesita ser declarado como publico.

Un objeto puede estar declarado como publico (para poder utilizarlo 'desde afuera') y ser utilizado como privado si se esta en el mismo entorno, en el caso de dudas la ruta absoluta SIEMPRE funciona.
(quizás rectificado el código publicado puedas apreciar diferencias, intentarlo haciendo modificaciones parciales, te ayudara a entenderlo)

------------------------------------------------------

En líneas generales una relación 1-1 solo tiene sentido en tablas con mas de doscientos campos (el máximo es menor de 255 campos)

Si en un formulario solo se necesitan parte de los campos de una tabla, se logra con una consulta y en una consulta se pueden añadir campos de mas de una tabla (utilizando o creando relaciones temporales entre ellas).

En base a todos los campos en la misma tabla:
Para el formulario [F_CARGA_INTERVENCION_EOE] se utiliza una consulta en la que se desprecia a los innecesarios.
Para el formulario [F_MOTIVOS_CATEGORIAS_DATOS] se utiliza otra consulta con los campos [Id_intervencion], [cdro_1], [cdro_2], [cdro_3] y [cdro_4]

El campo [Id_intervencion] se utilizara en la apertura de [F_MOTIVOS_CATEGORIAS_DATOS] o bien como filtro en su evento LOAD para obtener la sincronización de ambos.

En tu código convendría que todos los objetos (sus eventos) se declarasen como públicos para que sean accesibles desde ambos formularios y analiza si aporta alguna ventaja el utilizar dos tablas para definir las propiedades del mismo registro.

¿Los codigos para referenciar que transcribiste arriba se colocan en los eventos de los respectivos formularios o por ej para referenciar los combos del formulario B lo puedo hacer desde evento "despues de actualizar" de cdro 1?


Referenciando a [cdro_1..4] desde [F_CARGA_INTERVENCION_EOE]
Me.[cdro_1] ¿Refresh?
Forms.[F_MOTIVOS_CATEGORIAS_DATOS].[cdro_2]. ¿acá iriía el requery método o función?
Forms.[F_MOTIVOS_CATEGORIAS_DATOS].[cdro_3]
Forms.[F_MOTIVOS_CATEGORIAS_DATOS].[cdro_4]

Si se accede de forma correcta a los objetos, se tiene acceso a (casi) todas sus propiedades (el casi son las posibles excepciones), el dato que contiene esta en su propiedad Value (no siempre se utiliza, ya que es la que devuelve por defecto).

Hay otras propiedades de los objetos que solo están disponibles en determinadas circunstancias, por ejemplo la propiedad Text
Esta propiedad solo esta disponible para el objeto activo y hace referencia al valor que se le esta asignado en tiempo de ejecución (lo que se esta tecleando y permite obtener la parte de la cadena introducida en tiempo real), es util para ir filtrando según se introducen caracteres.

Otra pueden ser la propiedad Parent que solo existe para los formularios cuando hacen la función de subformularios, es un símil a 'Me' para el formulario activo, Parent es su 'equivalente', referencia desde el subformulario a objetos del formulario principal (o al que pertenezca como objeto).

No logro que me funcione el código desde combo 1 . me sale error 2450 "No se encuentra formulario F_MOTIVOS_CATEGORIAS_DATOS"

Public Sub cdro_motivo_intervencion_AfterUpdate()
Forms![F_MOTIVOS_CATEGORIAS_DATOS]!cdro_motivos_categorias = vbNullString
Forms![F_MOTIVOS_CATEGORIAS_DATOS]!cdro_motivos_categorias.Requery
Forms![F_MOTIVOS_CATEGORIAS_DATOS]!cdro_subcategorias_motivos = vbNullString
Forms![F_MOTIVOS_CATEGORIAS_DATOS]!cdro_subcategorias_motivos.Requery
Forms![F_MOTIVOS_CATEGORIAS_DATOS]!cdro_sub_subcateg_motivos = vbNullString
Forms![F_MOTIVOS_CATEGORIAS_DATOS]!cdro_sub_subcateg_motivos.Requery
End Sub

Es que cuando escribo Forms tampoco me aparece el buscador del panel donde despliega automaticamente el nombre de los formularios

Sospecho que deberías repasar este post: 08/06/2024 15:54:15

La única forma de que funcione ese código esta en añadir un condicional que verifique si F_MOTIVOS_CATEGORIAS_DATOS esta abierto.

Si un formulario esta cerrado (para Access) NO EXISTE.
(es como una receta de cocina: solo podrás catar el punto de sal si la estas cocinado o la has cocinado y queda algo que catar).

Cuando se abre un formulario en modo dialogo, este toma el control y mientras no pierda esa cualidad (la cualidad MODAL) mo permitirá 'interacción física' al resto de la aplicación.

Para acceder a un combo en otro formulario (físicamente para cambiar un dato en el) es imprescindible CERRAR el formulario abierto en modo MODAL y cuando se cierra un formulario .... deja de existir (la receta no salió bien y acabo en el cubo de los desperdicios)

Se tiene que reiniciar el ciclo (y mejor desde cero).

(Pero eso puede tener algunos problemas colaterales, por ejemplo: visualizar los datos de F_MOTIVOS_CATEGORIAS_DATOS)

Bueno, finalmente decidí colocar todos los combos en el mismo formulario A, parece lo más apropiado, y modificar el resto de consultas y formularios asociados que habían sido armados con el diseño previo. Por otro lado, creo que no llegué a comprender de todos modos como poder sincronizarlos en dos formularios separados ni las ventajas de hacerlo . Agradezco mucho la colaboración para el tema abierto por mí en esta oportunidad bajo el título en cuestión.

Es una opción que resuelve el problema, aunque implique un cambio radical en el diseño original.

La duda que me queda es porque el empeño en repartir en varios formularios una serie de combos diseñados para funcionar en cascada.

Si es (era) indispensable tener uno de ellos en el principal, bastaba con poner a los cuatro en el emergente, al entrar se sincroniza el combo1 del emergente con el combo1 en el principal y tras modificarlos a placer (y previo a cerrar el formulario emergente), se ‘sincroniza' al combo en principal con su copia en el emergente.

Incluso (en el principal) se cambia el combo por un cuadro de texto y no solo mostraría el dato del combo1, podría mostrar los valores de todos o parte de los combos, simplemente concatenándolos.

Sobre las ventajas de tenerlos en un formulario aparte, es solo metodología de diseño (por ejemplo que para unos sea de solo lectura y otros tengan permisos de creación/edición), que se cargue (y se cambie) más rápido el registro o que se utilice (el formulario emergente) como una calculadora a la que se le proporcionan datos y solo se recupera el resultado final.

Lo que si puede ser tema a debatir es que ventajas pueda tener el mantener datos en tablas diferentes con una relación (1-1)