Access - problemas en cálculos realizados en formularios

Hola a tod@s, tengo un formulario donde a partir de valores en ciertos textbox, calculo otros, la cosa no va mal del todo, aunque no lo hace automáticamente, es decir al generar el evento en la textbox del calculo según he leído lo hago mediante el lostfocus etc... que sucede que el calculo no se ve en la textbox hasta que no me meto en esa textbox y luego me salgo, no se que evento invocar para que ese calculo se haga automáticamente, es un engorro tener que llevar el cursos al textbox cada vez que quiera ver el resultado de ese calculo. he probado otros eventos pero en ninguno el calculo es automático.
el otro problema que tengo es que estos cálculos los he implementado con 180 registros en la BBDD claro al no hacer los cálculos automáticamente debería de entrar a cada registro ir al textbox de l resultado, entrar y salir de él, lo cual multiplica el engorro de manera exponencial.

Resumiendo tengo dos problemas el calculo no se hace como una calculadora y no me actualiza los cálculos a los 180 registros que tengo en mi BBDD.

espero vuestras respuestas

gracias por vuestra gran ayuda

Opciones hay varias y la mas idónea será una que se basase en lo que actualmente se esta haciendo (mas bien en 'como' se esta haciendo), dado que eso a momento actual es desconocido, las vías alternativas (entre otras) son:

.- Ejecutar un 'recalc' del formulario (actualizaría todos los objetos calculados)
.- ejecutar un 'repaint' (repintado) actualiza la presentación de todos los objetos (no recalcula NADA)

gracias anónimo , el problema es que nunca he trabajado con ese procedimiento y no se muy bien donde colocarlo.


Sería esto? lo he puesto en el código del formulario y no hace nada, es decir si quiero que los cálculos se ejecuten por haber cambiado los números de los textbox debo ir a cada uno de ellos entrar y salir , así los cálculos se ejecutan pero no automáticamente.

gracias por tu ayuda

este es mi código, por si te puede ayudar a ver que funciona mal, saludos.

Creo que no 'ves' al formulario como un conjunto de partes....

El evento mas utilizado para interactuar con los objetos, es el evento 'después de actualizar' (solo se ejecuta si cambia algo en serio), el de perder el foco (que suele ir detrás en el orden natural), se ejecuta siempre aunque no se cambie nada.

Seria una buena praxis el verificar de forma previa al calculo que todos los factores que intervienen tienen valores adecuados (así se evita dividir por cero o sumar valores nulos o ……..)

Hay infinidad de ocasiones en que se pueden agrupar los cálculos y verificaciones repetitivos en una subfunción (así se evita repetir lo mismo en un montón de sitios, y en caso de un mantenimiento es mas sencillo solucionar errores o hacer modificaciones.

Hola anónimo, ciertamente mis conocimientos de access son limitados y mas aun en lo que se refiere a programación e interpretación de eventos, esto es algo mas que evidente.

Los eventos que nombras los he colocado porque son los que leyendo he visto que son los mas empleados, sin embargo como te cuento o no hacen lo que yo espero o esos eventos no son para lo que yo los quiero, tampoco se si lo que quiero hacer se puede hacer. Pero me cuesta creer que una base de datos sea incapaz de hacer un calculo y reflejar el resultado de ese calculo empleando dos textbox para mostrar el resultado en un tercero.

me gustaría saber a que te refieres con "después de actualizar' (solo se ejecuta si cambia algo en serio)"? que debería de cambiar ?

respecto a lo que comentas de valores adecuados no creo que sea el problema puesto que al ir a los textbox implicados y perder el foco el calculo se realiza sin problemas.

No se si el orden de los eventos es importante y si uno puede inhabilitar al siguiente.


gracias por tu ayuda, me es de gran utilidad para seguir investigando, se que al final lo conseguiré, hace dos meses no pensaba haber generado una base de datos con las capacidades que estoy consiguiendo.

saludos

Lo de 'cambiar en serio' no es un juego, intenta definir esas situaciones en las que se cambia un dato y antes de darlo por aceptado se utiliza la tecla 'Esc' para abortarlo (se hicieron cabios en los objetos, pero no fueron consolidados)

Los eventos solo responden a las interactuaciones con el usuario o cuando se crea un programa que lo emula (al usuario).

Se basan en dividir una acción en diferentes pasos, por ejemplo, el caso de salir de casa (el mas habitual, no todos tienen mayordomo)
Una de las primeras acciones seria ir hacia la puerta (que recibiría el foco, es nuestro objetivo)
Otra el asir el pomo (pero aun no lo giras)
Otra el giro del pomo (que es la acción en si misma)
...abrir la puerta, salir, cerrarla y por fin perder el foco de nuestra atención porque se comienza con otra cosa (por ejemplo ir al medio de transporte)

Si en plena acción de salir apreciamos que llueve, puede interesarnos el hacerse con un paraguas (abortaríamos la salida)
o puede que queramos verificar si quedo bien cerrada esa puerta (después de actualizar el paso y cierre de la puerta)…

Esa es la idea de los eventos.

Normalmente Access cuando se efectúa un calculo y se le asigna el resultado a un objeto cuadro de texto -las etiquetas lo pueden mostrar pero con otro método- lo muestra y punto
Hay veces que tarda porque prioriza la ejecución de otras acciones, pero cuestión de instantes normalmente (si el calculo es abusivo como por ejemplo actualizaciones masivas, puede dar lugar 'parecer' bloqueado.... pero no es Access es el sistema operativo y sus niveles de prioridad de las acciones).

¿Por qué no se muestra en este caso? … pues depende del entorno, es fácil (cuando aun no se tiene un estilo definido de programar) el liarse entre los objetos nominados por nosotros y los que nomina Access en automático, puede darse el caso de trabajar con uno y intentar que lo muestre el otro)
Puede darse el caso de confundir la etiqueta con el objeto cuadro de texto y …
En fin que solo se puede diagnosticar con veracidad a un enfermo tras una revisión presencial (los traductores no siempre son fieles aunque pongan todo su interés).

Por lo que veo es complicado resolver el problema, ya que no se sabe si es por el codigo o por el sistema operativo o por los dos.
Lo dejare así y haré los cálculos cuando exporte a Excel otra cosa no se me ocurre.

gracias por tu tiempo

saludos

El único problema real (bajo mi punto de vista) es carecer de todo el conjunto para poder verificar si cada cosa esta en el lugar que se supone que debería estar, esto es: una copia simple del formulario que esta fallando.

Que tarde en mostrarse una información 1 milisegundo o 10 por causas ajenas (por ejemplo en otra ventana de esa maquina un proceso de tratamiento fotográfico o que esa maquina esta dando servicios de Servidor compartiendo aplicaciones) no debería ser el culpable de no mostrarse, lo haría si se le deja tiempo para hacerlo.

Si no de muestra es porque la programación no cumple con los requisitos básicos y el que tiene el problema (a momento actual) no tiene la capacidad analítica suficiente para hacer una autopsia forense (y los forenses solo pueden estimar causas tras un análisis, el resto son teorías o utopías que solo podrían ayudar a otro forense ante un atasco).