Access - Actualizar

Buenas tardes, como puedo actualizar un subformulario si cambia mi formulario, ya intente con Me.Repaint,
Me.Recalc, Me.Requery

y asi tambien y nada

Form_Sub_Detalle_Pedidos.Requery

Alguien me podria ayudar, por favor

Esto lo estoy poniendo despues de actualizar la etiqueta del formulario que cambia, y lo que quiero que me modifique es una etiqueta que depende del formulario

Exactamente que deseas lograr?

Las actualizaciones se pueden hacer en tres niveles del mas ligero al mas profundo son:

Repaint: redibuja la pantalla, es muy util cuando se esta en un proceso muy largo para mostrar los mensajes (pausa la ejecucion para refrescar la pantalla y mostrar el mensaje que de otra forma solo se vería al finalizar el proceso)

Recalc: lo mismo que Repaint, pero actualiza los objetos calculados (las sumas, totales y todos aquellos que dependen de algún calculo o proceso)

Requery: lo mismo que Recalc a lo que añade volver a cargar el origen de datos del objeto

Cada uno tiene su utilidad y no siempre el mas alto es es el mas adecuado.

Hola otra vez
En mi formulario tengo la etiqueta TipoCliente, la cual en el subformulario me pone el precio de acuerdo al tipo de cliente que elijo, ahora si lleno los campos del subformulario, pero en ese momento cambia el tipo de cliente, y lo cambio, debería de cambiarme los precios por cambiar el tipocliente.

Nota: Para poder hacer que funcionara mi evento, tuve que poner tipo cliente en el detalle y en pie del subformulario.

Me imagino que debería usar recalc o requery, pero no sé como, ya lo intenté y no me sale.

Gracias por todo tu apoyo.

Sospecho que no partimos de los mismos conceptos y ello es el mayor problema.

Una etiqueta es (por buscar un símil) una pintada en un muro o una pancarta con propaganda y como tal no interfiere en el semáforo que controla el paso de peatones.

No veo ninguna necesidad de que (una Etiqueta) tenga que estar en la sección detalle y la sección pie del formulario para que ¿funcione?.

Me explico otra vez, creo que dije mal.

En formulario (Frm_Pedidos) tengo un cuadro combinado TipoCliente, que está en detalle.


En el Sub_Detalle_Pedidos, en el pie de formulario puse el cuadro de texto TipoCliente con el origen de control:
=Formularios![Frm_Pedidos]!TipoCliente.

Asi que cuando cambio por ejemplo la clave, me busca el precio de acuerdo al tipo de cliente, eso ya me lo hace bien.

Pero si por ejemplo quiero cambiar el TipoCliente de mi formulario, no me cambia los precios, es por eso que necesito algo para que me de la instrucción que me cambie el precio si cambia el tipo de cliente, sin cambiar la clave.

Buenos días:

Requery se utiliza para que se vuelvan la leer los datos del recordset que se muestra en el formulario y este esté actualizado y no sé si tiene nada que ver con lo que quieres. Lo digo por eso de que modifique una etiqueta que depende del formulario. No tengo ni idea de a qué te puedes estar refiriendo con eso. Mira a ver si puedes explicarte un poco mejor, a ser posible, usando las denominaciones correctas de los distintos elementos de Access.

Un saludo,

Norberto.

Buenos dias Norberto, no se mucho de Access y poco a poco he avanzado, tengo una etiqueta en mi formulario (tipoCliente) que me da el precio en mi subformulario de acuerdo al tipo, si quiero cambiar el tipocliente, quiero que me cambie el precio.

Hola,

Prueba:

Aun no he recibido la aclaracion que solicite, aun asi creo que es necesario aclarar puntos.

Las etiquetas no tienen dependencia de los datos, por lo que Requery o Recalc no tendrán efecto sobre ellas, lo único que podría hacer algo es Repaint (y no creo que sea necesario).

Para modificar el contenido de un objeto etiqueta, el nuevo contenido se le ha de asignar a su propiedad CAPTION y la actualización acostumbra a ser inmediata.

Un entorno:
El objeto activo es el formulario principal (y en el se esta ejecutando el proceso).

La sintaxis para hacer referencia a un objeto del subformulario (formulario [Vacaciones]) y a su etiqueta [Destino], el dato a asignarle esta en el formulario principal, en un combo [Cbo_Paises] que lo devuelve por defecto..

Me.Vacaciones.Form.Destino.caption = Me.Cbo_Paises

el tipocliente del formulario es cuadro combinado, me equivoque, dejame estudiar lo que me dijiste para poderlo aplicar, dame tiempo.

error 2465 no ha encontrado en campo Form_Sub_Detalle_Pedidos, y ya cheque y esta bien escrito, esto lo pongo despues de actualizar mi etiqueta del formulario.

Prueba llevando el foco a un control del subformulario:

Leyendo mejor creo que esto no es lo que necesitas, tú quieres que el precio que te indica en una etiqueta del formulario tipoCliente, aparezca también en una etiqueta del Form_Sub_Detalle_Pedidos, es correcto?

Si es así, es casi lo mismo, siempre has de llevar el foco al subformulario para poder operar en él. En este caso no necesitas un requery, creo que necesitas copiar el valor que quieres del fomulario y reflejarlo en el subfomulario.

Pego lo que comente arriba
Me explico otra vez, creo que dije mal.

En formulario (Frm_Pedidos) tengo un cuadro combinado TipoCliente, que está en detalle.


En el Sub_Detalle_Pedidos, en el pie de formulario puse el cuadro de texto TipoCliente con el origen de control:
=Formularios![Frm_Pedidos]!TipoCliente.

Asi que cuando cambio por ejemplo la clave, me busca el precio de acuerdo al tipo de cliente, eso ya me lo hace bien.

Pero si por ejemplo quiero cambiar el TipoCliente de mi formulario, no me cambia los precios, es por eso que necesito algo para que me de la instrucción que me cambie el precio si cambia el TipoCliente de Frm_Pedidos, sin cambiar la clave o prodcuto de Sub_Detalle_Pedidos.

En mi diseño virtual, el campo tipo de cliente es un atributo del cliente y no tiene sentido que se elija en un combo (con la excepción de 'al crear la ficha del cliente').

Si sobre la marcha se cambia el dato 'TipoCliente' habrá que recorrer registro a registro el subformulario para recalcular el precio.
Un recalculo de otro tipo a lo sumo afectaría a los nuevo registros y/o al registro activo.

Por cierto, el campo TipoCliente no tiene sentido que sea 'una etiqueta' (el combo no lo es) y no se debería utilizar una etiqueta para la funcionalidad que le corresponde a un cuadro de texto (que con DLookup obtendría de la ficha del cliente el precio que le correspondiese)

Copio lo de arriba que te mencioné:

----------
Me explico otra vez, creo que dije mal.

En formulario (Frm_Pedidos) tengo un cuadro combinado TipoCliente, que está en detalle.


En el Sub_Detalle_Pedidos, en el pie de formulario puse el cuadro de texto TipoCliente con el origen de control:
=Formularios![Frm_Pedidos]!TipoCliente.

Asi que cuando cambio por ejemplo la clave, me busca el precio de acuerdo al tipo de cliente, eso ya me lo hace bien.

Pero si por ejemplo quiero cambiar el TipoCliente de mi formulario, no me cambia los precios, es por eso que necesito algo para que me de la instrucción que me cambie el precio si cambia el TipoCliente de Frm_Pedidos, sin cambiar la clave o prodcuto de Sub_Detalle_Pedidos.


---------

Si tengo que correr registro a registro, del formulario, tengo que poner la clave de nuevo para que me cambie el precio, si es asi es mejor borrar todos los datos del subformulario para empezar de nuevo, y eso es lo que quiero evitar.

Paulina, una cosa es que (de momento) no sepas como hacer algo y otra es que no se pueda hacer.

Supongo que si en tu entorno hay 'personitas' habrás aplicado (o visto aplicar) la metodología de no darle comidas que a su edad y madurez no puedan digerir, pero en cuanto cambian (y lo acostumbran a hacer muy rápido) abren su paladar a nuevos sabores y al final algunos llegan a ser grandes Chef (tómalo como referencia).

No hace falta volver a introducir los datos, con un bucle se puede volver a recalcular el precio adecuado al tipo de cliente y la referencia (el tipo de cliente) puede ser ese combo que esta en el formulario principal (y que no seria necesario si TipoCliente fuese uno mas de los atributos del cliente).

A mi ese método (el elegir el tipo de cliente en un combo) me parece inadecuado, que un cliente obtenga uno u otro precio a capricho de quien introduce los datos no suele resultar.

Ahora te pregunto: si dentro de unos días tienes que verificar las ventas o las salidas 'porque no cuadran los números' ¿crees que tienes los suficientes datos para verificar si 'los números' son correctos?.

Quizás hoy no le des importancia a ese detalle, pero créeme que ese día llega cuando menos se le espera.

Gracias, voy a investigar lo de los bucles.

Porque te digo que hay tipo de clientes? Porque donde trabajo hay como 5 tipos de clientes o grupos, si en un momento la persona que va a usar el programa se equivoca al elegir el tipo, quería cambiar el precio al solo modificar tipo de cliente en formulario. Esto lo hice para simplificar, y no buscar por nombre de cliente. Con una sola letra tendría.

Lo de: Ahora te pregunto: si dentro de unos días tienes que verificar las ventas o las salidas 'porque no cuadran los números' ¿crees que tienes los suficientes datos para verificar si 'los números' son correctos?. No te entendí a lo que te refieres.

Lo de tu comentario de las ventas ha de ser lo mismo que porque tipo de cliente y no nombre de cliente, creo.

Viéndolo de otra manera, puede ser que mejor tenga en el formulario nombre, y me cambie directo el tipocliente de acuerdo al nombre de este,.
Tengo que modificar y tardo en hacerlo, y ya de ahí si quiero cambiar el nombre del cliente que a su vez cambia el tipo de cliente, darme lo que quería desde un principio, si cambio tipo que cambie el precio,en automático.

Creo que nuestro ángulo de vista es diferente y el único que al final valdrá será el tuyo porque asumo que la aplicación esta planificada y estas siguiendo ese plan.

Si de verdad necesitas cambiar el precio en tiempo real en función del valor en el combo, solo has de publicar el calculo actual que utilizas e intento generar ese código, si admites un punto de vista (debería funcionar con los datos actuales)

Asumiendo que el precio se calcula al crear el nuevo registro en función del elemento seleccionado en el combo, supongo que se puede cambiar la selección en el combo para cada registro y en algunos registros un precio y en otros otro diferente (para el mismo cliente).

Si te interesa mantenerlo así, para recalcular todos los registros del subformulario añade un botón (le puedes denominar 'recalcular' o algo similar), y un con un click en él se uniformizan los precios en base al elemento seleccionado en el combo (coexistirán ambos métodos).

Gracias lo voy a internar con el botón, te escribo si pude.

Paulina, pruebe con esto:


En donde nombreSub es el nombre del subformulario y nombrecontrol es el nombre del control que depende del formulario principal, creo que un caso es TipoCliente.

Nada.

En mi formulario Frm_Pedidos, tengo TipoCliente, y en mi subformulario Sub_Detalle_Pedidos tengo esta macro que la pongo en el evento despues de actualizar clave o producto:

Precio = DLookup("Precio_" & [TipoCliente], "Tbl_Productos", "CLave= '" & [Clave] & "'")
Me.Cantidad = 0

donde me está buscando el precio de acuerdo a al tipocliente del formulario y segun la clave del subformulario, esto me lo hace bien, cuando pongo la clave o el producto.


Si cambio el TipoCliente del formulario, queria que me actualizara el precio, es decir ahora en lugar de los eventos despues de actualizar clave o producto, me actualizara el precio.

No consigo como, ya hasta lo intente con un boton.

Creo que puedo solucionarlo, como hago que el origen del control que lo tengo asi:

=[Formularios]![Frm_Pedidos]![TipoCliente]

me lo cambie luego luego que cambio el tipo de cliente del formulario.

Te propongo este código para el botón actualizar:
Al subformulario con las líneas de venta le he llamado [Ventas_Det] y el boton [BtnActualizar] esta en el formulario principal.




Para actualizar el registro activo del subformulario (solo el registro activo) la sintaxis básica es la misma, basta con cambiar la referencia a los objetos.
(están en el subformulario y el cambio se efectúa en el formulario principal ... o eso quiero suponer).

Hay que asegurarse de que hay un elemento activo en el subformulario y también hay un elemento seleccionado en el combo [TipoCliente]


He intentado adaptar el codigo a los nombres de tus objetos, espero haberlo logrado.

Gracias por ayudarme, ya hice el botón, pero no sé cómo ponerle nombre las líneas de venta. Disculpa.

Paula, no entiendo cual es el problema...
Si creas un botón en el formulario principal y (en la Vista diseño del formulario) acudes a sus propiedades, habrá una pestaña 'Eventos'.

Selecciona la de los eventos, y en ella el evento Click y (en lugar de seleccionar una macro) , selecciona 'Procedimiento de evento' y click en los puntitos del final.

Aparecerá la ventana de VBA (que algo ya conocerás) con la definición del evento y espacio para darle contenido, deberá quedar igual que el que he publicado (la cabecera y pie ya las tienes, yo le adjudique un nombre y tu tendrás el que Access le asignó).

Un consejo, si deseas que tenga el mismo nombre se lo has de adjudicar ANTES de crear eventos, pues si lo haces 'después' al cambiar de nombre al objeto los eventos se liberan (Access no los renombra).

TipoCliente es como he denominado al combo en el ejemplo, el método es el mismo en modo diseño acude a sus propiedades, activa el evento (en este caso el 'Change') y pega las líneas del que aporte.

Me ha basado en tu publicación para utilizar nombres y 'suponer' el resto de datos necesarios espero que te sea útil entre pagina y pagina del manual que (supongo) estarás estudiando.

Ya quedo lo del botón, pensé que cuando dijiste líneas de venta, se ponían nombre a las filas del subformulario, perdón, a lo que te referías era al nombre del subformulario.

Gracias!!!

De verdad gracias por tu paciencia. Quedó como queria