|
Bueno esta explicacion quiza no sea muy ortodoxa pero lo voy a explicar tal y como yo lo entiendo
En R3 existen dos "compiladores" diferentes para tener separada la parte grafica y de presentacion de datos de lo que es el tratamiento de los datos
- El compilador de los report, funciones, clases, etc
- El compilador de las dynpros
Por ejemplo esta es la razon por la que las sentencias module, chain, etc no se pueden usar en los reports y los write, perform, etc no se pueden utilizar en las dynpros
La gran mayoria de desarrollos que hacemos tienen tanto una parte de tratamiento de datos como luego otra parte visual donde mostraremos al usuario los resultados, por lo tanto debe existir una comunicacion entre estos dos compiladores, si por ejemplo yo cambio el valor de una variable, de alguna manera se le debe comunicar a la dynpro que tiene que cambiar el valor de dicho campo, esta comunicacion se hace por rfc
Si cada cambio que hicieramos se comunicara instantaneamente, por ejemplo imaginemos una dynpro que tuviera 100 campos, se establecerian 100 conexiones rfc para la sincronizacion, esto obviamente penalizaria muchisimo el rendimiento por lo tanto lo que se hace es encolar las llamadas y procesarlas posteriormente todas a la vez
Esta es la razon por la que algunos cambios que hacemos que implican cambios "visuales" no los vemos automaticamente, el cambio esta hecho, pero esta encolado y por lo tanto la dynpro todavia no se "ha enterado"
Para forzar la sincronizacion existe el metodo FLUSH y el metodo DISPATCH es un metodo que tiene una funcion similar solo que es para la sincronizacion entre eventos
En resumen, si en nuestro programa realizamos una operacion que implica algun cambio en la dynpro (actualizacion de campos, grids, lanzamiento de okcodes, etc) y queremos que sea instantaneo utilizaremos el metodo dispatch para el caso de que lo que este implicado sea un evento y el metodo flush para todo lo demas
|