al Cambiar Preferencias informar a todas las ventanas afectadas

[dec]

Hola,

Seguramente no te sirva lo que diga Lepe, o sea algo que ya tuvieras en cuenta. Me extrañaría que no fuera así. Alguna vez hize alguna aplicación con su correspondiente ventana de opciones. Dichas opciones podían aplicarse o "aceptarse".

En el formulario principal de la aplicación se contaba con dos métodos: uno para guardar las opciones "actuales" y otro para recuperar las opciones. Dichas opciones se guardaban en el Registro de Windows. Así, cuando se habría el formulario de opciones (desde el formulario principal), al cerrarse el primero "aceptando las opciones" (no cancelando) se llevaba a cabo la ejecución del procedimiento para guardar las opciones del formulario principal.

Al cerrarse el formulario de opciones, acto seguido, quiero decir, se ejecutaba el procedimiento para recuperar las opciones, de manera que estas se aplicaban en el formulario principal, naturalmente. Ya con más formularios implicados... no sé yo cómo sería el caso.

Pero, ya digo: contaba con un procedimiento para guardar las opciones y otro para recuperarlas. Cuando se abría el formulario de opciones se mostraban las actuales al usuario. Cuando el usuario cambiaba dichas opciones, primero se guardaban, utilizando el procedimiento adecuado, y luego se leían, de manera que los cambios surtieran efecto.

Me parece que no he dicho nada... o que he liado la cosa más, pero, en fin, es lo que puedo decir. Ahora, que esto pueda mejorarse... hacerse mejor... no me cabe la menor duda de que así es.

[[seoane]]

Le he estado dando vueltas al asunto, y se me ha ocurrido algo sencillo, aunque no se si te servirá. Defines un nuevo mensaje WM_ACTUALIZAR y en todas las ventanas interceptas ese mensaje. Dentro del procedimiento que trata ese mensaje pones todo lo necesario para actualizar la ventana, de este modo cuando quieras actualizar solo tienes que mandar ese mensaje a todas las ventanas abiertas. Solo necesitaras la API SendMessage, así que no tendrás problema en llamarla desde cualquier unit.

Es solo una idea, ahora quedaría saber el handle de todas las ventanas, aunque no creo que sea difícil averiguar el handle de las ventanas hija, o en ultimo caso llevar una lista.

EDITO:

Añado un ejemplo de lo que quiero decir. En este ejemplo todos los hijos interceptan el mensaje de la misma forma, pero cada uno podría interpretarlo como quisiera, además si algún formulario no lo interceptara no pasaría nada, simplemente seria ignorado.

EDITO 2:
En el ejemplo para mandar el mensaje a todos los formularios hago esto:

Código Delphi [-]
for i:= 0 to frmMain.MDIChildCount - 1 do
   SendMessage(frmMain.MDIChildren[i].Handle,WM_ACTUALIZAR,0,0);

Pero se me ocurre otra forma que todavía hace mas independiente cada formulario del resto:

Código Delphi [-]
for i:= 0 to Screen.FormCount - 1 do
   SendMessage(Screen.Forms[i].Handle,WM_ACTUALIZAR,0,0);

PD: Como Lepe no responda rápido, seguro que va a haber un "EDITO 3"

[[Lepe]]

Gracias dec, uso algo parecido, aunque la mayoría de las opciones las guardo en la propia base de datos (tabla config), en un entorno multiusuario es imprescindible, ya que el usuario puede cambiar de máquina y al hacer el login, tiene toda su configuración.

seoane: Gracias por el ejemplo , no hace falta que te expliques más porque ya he captado perfectamente la idea.

Es más en los parámetros wmParams podría enviar un entero indicando qué opciones se han modificado, algo así como definir constantes del tipo:

Valor   Significado
  1        modificado opción de desplegar
  2             "             "      una
  4             "             "      dos
  8            "               "
 16

Si se envía un 6 ya se sabe que hay que "recargar" las opciones "una" y "dos"

Tengo que implementarlo para ver las posibles "incomodidades" que produzca; de momento es el método que más me gusta.

Tengo poco tiempo ahora mismo... pero volveré

[roman]

A esto, en OOP se le conoce como el patrón del observador. La VCL lo utiliza en muchas partes, por ejemplo, cuando el DataSource comunica a todos los controles conectados (suscritos) a él, acerca de un cambio.

Con el método de seone recuerden que también pueden pasar como parámetros de los mensajes, apuntadores a un objeto o registro, disfrazados de enteros. Digo esto porque así puede pasársel una estructura de datos mucho más rica que indique qué cambios y cuáles hubo.

// Saludos

[[Lepe]]

Muchas gracias roman por el enlace, de hecho eso mismo he implementado con el TEventAlerter, pero como empezaba a ver "incomodidades" (pueden ser muchos mensajes registrados en la aplicación, muchos callbacks esperando dicha notificación, saltos de eventos en ocasiones inesperadas) ... vamos ... como la propia VCL en TDatasets (tú lo has comentado en otras ocasiones y estoy totalmente de acuerdo, es un jungla de eventos), quería saber si hay otra opción.

A ver, no pido milagros, sino poder reutilizar código y que sea algo "elegante". Si no puede ser ambas cosas al mismotiempo, usaré la que mejor se adapte.

Lo que si me gusta del TIBEventAlert es que puedes saber todos los mensajes que están registrados en un momento determinado y al menos saber cuantos observadores lo esperan. Ayuda un poco cuando se está depurando una aplicación.

Por razones que no vienen al caso, tengo que posponer mi trabajo unos días, así que no entraré a menudo en los foros, pero esto, no quita importancia a todos vuestros esfuerzos y consejos, Gracias.

Saludos

[[Lepe]]

Pues al final me he decidido por el patrón del observador, pero nada complejo:

Un TStringlist almacena el nombre de cada "alerta", cada alerta lleva asociado un TObjectList.

Cada elemento del TObjectList es un objeto en el que se puede almacenar:
- Puntero hacia un procedure of object
- Puntero hacia un procedure.
- Tipo de Puntero (define cual de los dos anteriores se ha usado).
- Nombre del observador (para depurar).

Todo queda encapsulado en un TObject con los métodos:
- AddAlert - > se registra un observador
- DeleteAlert-> se elimina un observador
- ExecuteAlert-> se lanza la notificación de una alerta determinada a todos sus observadores
- AlertsNamesAndObservers -> Depuración: muestra todos los nombres de las alertas, el total de observadores y el nombre de cada uno.

Los 3 métodos iniciales están sobrecargados para llamarlos con un "procedure of object" o con un simple "procedure"

Le veo una pequeña lista de futuros cambios (de momento se queda como está ):
TO DO: - ¿Derivar de TComponent y añadir el FreeNotification?
Razon: Si el usuario del módulo no Elimina la alerta al hacer un .Free de la
ventana donde se encuentra el Callback, al llamar a Execute se
producirá un access violation.

- Añadir CriticalSection ¿?

Saludos y muchas gracias.

[Paoti]

Otro nivel con ustudes... cada día se aprende más.


Gracias.