Quería preguntarles si alguien leyó o hizo alguna vez algo similar.
Se me ocurre hace un procedimiento que actualize todos los controles visuales que muestran algun dato. Por ej: en un form de una factura, si agregamos o quitamos un producto, se debe actualizar los totales, ya se que el cleintdataset tiene la opcion agreggates por ejemplo.
Pero tengo un campo donde se ingresa el efectivo entregado por el cliente, y se autocompleta el vuelto en otro edit. si se agregaria otro producto aumenta el total y disminuye el vuelto. Osea me refiero a todos los cambios que puedan ocurrir.
Osea la idea seria llamar a este procedimiento en cada proceso que hace una modificacion. Y lo que haria seria resetear, volver a escribir todos los valores. De esta manera se centraliza esta tarea. Hasta podriamos trabajar con stringgrid y no dbgrid.
Eso que comentas es de lo más habitual, y necesario. Es inevitable la existencia de un hipotético método que se llame ActualizarFormFactura() y se encargue de hacer el trabajo.
La implementación real dependerá de tu diseño y tu capacidad creativa.
Si lo vemos desde lo más purista Orientado a Objetos, un enfoque a utilizar sería el patrón Observador. Ya se ha tratado en ocasiones este concepto. Es más hay código funcional de mi parte en el foro.
En pocas y resumidas líneas el patrón Observador plantea que existe dos tipos de clases: la Observable (llamada mayormente Sujeto) y la Observadora. La 1ra es la que va a estar en cambios y les notificará a todas las instancias de observadores que estén "registradas" en ser notificadas de algún cambio.
La idea es usar el principio "No me llames. Yo te avisaré cuando sea necesario". Generalmente uno está acostumbrado a verlo al revés. Si un objeto desea algo, se lo pide al otro.
Pero en ocasiones (sobre todo si van a ser muchos los interesados en interactuar con el objeto dependiente) el concepto es aconsejable invertirlo y hacer que sea el objeto sujeto a cambios quien avise "Hey, he cambiado X propiedad. ¿Hay alguien interesado en saber el valor?".
Tu clase observable puede ser TFactura, y como observadores podríamos citar el Form que está trabajando con la Factura, el form de reporte de facturas, etc.
En Delphi ya existe una implementación inspirada parcialmente en este concepto. Un ejemplo son los componentes Data-ware. Internamente los componentes se apoyan en unos objetos "links" que vinculan el TDataSource con los diferentes controles DB. El DataSource que actúa de intermediario, notifica a los controles de los cambios reales que se han efectuado en el TDataSet.
Pero... también hay situaciones en donde esta magia que nos ofrece Delphi se nos puede ir de la manos si uno no aplica un correcto diseño y control... Y ahí es cuando uno se debate la posibilidad de no usar Data-ware (recomiendo que te tomes el tiempo para leer ese enlace) y hacer el "trabajo duro". Ahí es cuando ya si se enfoca a aplicar el patrón Observador y hacer un diseño por lo general más purista OO y llegar a plantearse un diseño asistido por Capas.
Agustin Ortu y yo somos dos ejemplos de los que evitamos el uso de Data-ware.
Ahora bien ¿Merece llegarse a usar el patrón? No necesariamente, tu deberás evaluar que tanto pros como contras tendrás si lo aplicas... Ponte a pensar en cuantas clases sujetos y observadores tendrás, y/o si será util hacerlo pasar por una fachada como intermediario.
Dependiendo del "ruido" que te haga podrías tomar una decisión...
En ocasiones quizá no sea necesario malgastarse en usar Observer y directamente usar lo clásico:
1. Realizar la operación ABM en cuestión en la DB
2. Invocar los SELECTs que sean necesarios
3. Refrescar el contenido del form con lo obtenido de la consulta
Esto se podrá hacer por demanda... o hasta incluso hacer que sea automático cada x cantidad de segundos.
Insisto: que todo dependerá de tu creatividad y tu diseño. Pero de que se puede hacer seguro.
Saludos,