17 respuestas en este tema

[AngelF]

Hola. De nuevo por aquí y esta vez con una tontería pero que no sé cómo resolverla.

 

Con Codetyphon quiero crear un programa que muestre un formulario, realice alguna acción (por ejemplo mostrar unas estadísticas) y al cabo de unos segundos, cuando termine la acción, se cierre solo. Todo esto sin la intervención del usuario, es decir, el usuario no tiene que tocar ningún botón para iniciar la acción o cerrar el formulario.

 

Esto es sencillo, pero aquí viene el problema: el formulario se abre correctamente pero no se muestra en pantalla, tan solo se dibujan los bordes pero no el contenido, realiza la acción bien (sigue sin mostrarse) y justo unas décimas antes de cerrarse, se muestra y se cierra, con lo que no te da tiempo a ver nada.

 

Como no sé si me entiende bien, pongo un ejemplo muy sencillo: Tengo una aplicación con dos formularios, form1 y form2. En el principal, form1, pongo un botón que al hacer click me muestra el form2

delphi

procedure tform1.button1click(sender: tobject);
begin
  form2.ShowModal;
end;

El form2 quiero que muestre en un label una cuenta creciente de 0 a 10.000. Cuando llegue a 10.000 que se cierre automáticamente

delphi

procedure HagoAlgoySalgo; 
 
....
procedure tform2.hagoalgoysalgo;
var
  i: integer;
begin
  for i := 0 to 10000 do  //cuenta de 0 a 10.000
  begin
    Application.ProcessMessages;  //para que procese mensajes
    label2.Caption := IntToStr(i); //veo la cuenta en un label
    label2.Refresh; //refresco el label
  end;
  close; //cierro el formulario
end;           
 
procedure tform2.formshow(sender: tobject);
begin
  HagoAlgoySalgo;
end;

Bueno, pues al darle al botón del form1, no veo nada (o acaso veo los bordes del form2 pero el contendio es transparente, no veo el label2 contando) y cuando termina la cuenta, ves por una décima de segundo algo que se cierra inmediatamente.

 

He probado a poner la función HagoAlgoYSalgo en el OnPaint, pero me da el mismo resultado.

 

¿Alguna solución? Como véis, bastante tonto el problema...

 

Un saludo.

 

[AngelF]

Vale, me respondo yo mismo

php

procedure tform2.hagoalgoysalgo;
var
  i: integer;
begin
  form2.Refresh; //<-- Con esto se muestra el formulario
    for i := 0 to 10000 do  //cuenta de 0 a 10.000
    begin
      Application.ProcessMessages;  //para que procese mensajes
      //if (i mod 15) = 0 then form2.Refresh;
      label2.Caption := IntToStr(i); //veo la cuenta en un label
      label2.Refresh; //refresco el label
    end;
    Close; //cierro el formulario
end;

Poniendo form2.refresh antes de empezar el bucle, se muestra el formulario correctamente.

[Agustin Ortu]

Aún así creo que esta mal diseñado. Lo ideal es desde temprano acostumbrarse a programar bien. Lo digo porque lamentablemente yo lo aprendí tarde y ahora me quiero matar

Yo crearía una clase que haga ese trabajo, y le agregaria un evento OnFinished. De esa manera tu clase provee un mecanismo "decime que querés que haga cuando termine".

Ahora desde el teléfono no me dan ganas de escribir código pero te prometo un ejemplo más tarde

Igual para que lo vayas pensando

Enviado desde mi XT1032 mediante Tapatalk

[Agustin Ortu]

Bueno, como te decia, yo creo que lo ideal es crearse una clase que se va a encargar de realizar cierto proceso, y el Form simplemente sirve para interactuar con ella. Vamos a hacer tambien que tu clase pueda proveer un mecanismo de feedback (retroalimentacion) para poder, en este caso, mostrar el progreso
 
 

delphi

unit Unit2;
 
interface
 
uses
  Classes;
 
type
  TOnProgress = procedure(const ACurrent, ACount: Integer) of object;
  TBeforeStart = procedure(const ACount: Integer) of object;
 
  THacerAlgo = class
  private
    FOnProgress: TOnProgress;
    FCount: Integer;
    FBeforeStart: TBeforeStart;
    FOnCompleted: TNotifyEvent;
    procedure SetOnProgress(const Value: TOnProgress);
    procedure SetBeforeStart(const Value: TBeforeStart);
    procedure SetOnCompleted(const Value: TNotifyEvent);
  public
    constructor Create(const ACount: Integer);
    procedure HacerAlgo; overload;
    procedure HacerAlgo(const ACount: Integer); overload;
    property OnProgress: TOnProgress read FOnProgress write SetOnProgress;
    property BeforeStart: TBeforeStart read FBeforeStart write SetBeforeStart;
    property OnCompleted: TNotifyEvent read FOnCompleted write SetOnCompleted;
    property Count: Integer read FCount;
  end;
 
implementation
 
{ THacerAlgo }
 
constructor THacerAlgo.Create(const ACount: Integer);
begin
  inherited Create;
  FCount := ACount;
end;
 
procedure THacerAlgo.HacerAlgo;
var
  LCurrent: Integer;
begin
  if Assigned(FBeforeStart) then
    FBeforeStart(Count);
 
  for LCurrent := 0 to Count - 1 do
  begin
     // hacer algo :)
     if Assigned(FOnProgress) then
      FOnProgress(LCurrent, Count);
  end;
 
  if Assigned(FOnCompleted) then
    FOnCompleted(Self);
end;
 
procedure THacerAlgo.HacerAlgo(const ACount: Integer);
begin
  FCount := ACount;
  HacerAlgo;
end;
 
procedure THacerAlgo.SetBeforeStart(const Value: TBeforeStart);
begin
  FBeforeStart := Value;
end;
 
procedure THacerAlgo.SetOnCompleted(const Value: TNotifyEvent);
begin
  FOnCompleted := Value;
end;
 
procedure THacerAlgo.SetOnProgress(const Value: TOnProgress);
begin
  FOnProgress := Value;
end;
 
end.

delphi

unit Unit1;
 
interface
 
uses
  Unit2, Winapi.Windows, Winapi.Messages, System.SysUtils, System.Variants, System.Classes, Vcl.Graphics,
  Vcl.Controls, Vcl.Forms, Vcl.Dialogs, Vcl.StdCtrls, Vcl.ComCtrls;
 
type
  TForm1 = class(TForm)
    Button1: TButton;
    ProgressBar1: TProgressBar;
    Label1: TLabel;
    procedure Button1Click(Sender: TObject);
  private
    { Private declarations }
  public
    { Public declarations }
    procedure HacerAlgoOnProgress(const ACurrent, ACount: Integer);
    procedure HacerAlgoBeforeStart(const ACount: Integer);
    procedure HacerAlgoOnCompleted(Sender: TObject);
  end;
 
var
  Form1: TForm1;
 
implementation
 
{$R *.dfm}
 
procedure TForm1.Button1Click(Sender: TObject);
var
  LHacerAlgo: THacerAlgo;
begin
  LHacerAlgo := THacerAlgo.Create(1000);
  try
    LHacerAlgo.BeforeStart := HacerAlgoBeforeStart;
    LHacerAlgo.OnProgress := HacerAlgoOnProgress;
    LHacerAlgo.OnCompleted := HacerAlgoOnCompleted;
    LHacerAlgo.HacerAlgo;
  finally
    LHacerAlgo.Free;
  end;
end;
 
procedure TForm1.HacerAlgoBeforeStart(const ACount: Integer);
begin
  Button1.Enabled := False;
  Label1.Caption := 'Inicializando...';
  ProgressBar1.Min := 0;
  ProgressBar1.Max := ACount;
  ProgressBar1.Position := 0;
end;
 
procedure TForm1.HacerAlgoOnCompleted(Sender: TObject);
var
  Procesados: Integer;
begin
  Procesados := THacerAlgo(Sender).Count;
  Button1.Enabled := True;
  ShowMessageFmt('Termine y procese %d elementos', [Procesados]);
  Label1.Caption := 'Terminado!';
end;
 
procedure TForm1.HacerAlgoOnProgress(const ACurrent, ACount: Integer);
begin
  TThread.Synchronize(NIL,
  procedure
  begin
    Label1.Caption := Format('%d / %d', [ACurrent, ACount]);
    ProgressBar1.Position := ACount;
  end);
end;
 
end.

Fijate que le dimos la capacidad a los usuarios de la clase de suscribirse a "eventos" que sirven como bandera, avisan cuando pasa ciertas cosas y proveen informacion. De esta manera uno puede actuar en consecuencia

 

Hacer que una cosa suceda a otra es algo super facil de hacer en Object Pascal, el lenguaje fue pensado para ello (gracias a Dios!!)

[Delphius]

Interesante propuesta OrtuAgustin, has definido una especie de "single observer"    Lo que quizá podría rediseñarse es buscar la forma de "independizar" el sistema de notificación del proceso de las tareas.

Supongamos que tenemos varias clases "Hacer Algo", o varias tareas semi independientes y que nos interesa poder mostrar un proceso en cada una de ellas. Bajo el esquema que tu propones implicaría estar duplicando código, en concreto la parte de los eventos. Una alternativa podría ser definir una clase TProcess que define justamenta la interface común a todas: los eventos. Y luego heredar de ésta para añadir y adaptar la lógica por cada "Haz Algo". Por ejemplo, digamos quen tenemos pensado que una clase Ordene, otra que realice sumas y queremos ver una especie de proceso o avance por cada una. Asi de pronto podríamos tener una clase TSortProcess y TSumsProcess. Entonces dentro de sus propios métodos de interés y cuando éstas vean necesario invocar a los métodos OnProcess, BeforeStart y/o OnCompleted.

 

Me haz dado una interesante idea de diseño para mi actual proyecto. Quizá me sirva.

 

Saludos,

[Agustin Ortu]

Sabes que justo me entro a dar vueltas por la cabeza lo mismo; el problema es que es medio raro que me surgan estas ideas y no agarro ni el papel y lapiz; hasta que resulta que me vendria bien y ahi es cuando de a poco empiezan a tomar forma las cosas

 

Creo que una solucion para tener a multiples observadores seria almacenar alguna estructura con los eventos a procesar

 

Lo que decis sobre la herencia es correcto pero no queria complicar tanto el ejemplo. A veces estos cambios de paradigma cuestan un poco masticarlos, pero me parece que dar un paso de "todo en los forms" a "el form solamente muestra que pasa y nada mas" es crecer muchisimo

[Agustin Ortu]

Se que esto no tiene mucho que ver con lo que pusiste en tu mensaje pero creo que puede resultar interesante ir por este lado tambien


A ver que tul:
 
Form:

delphi

unit Unit1;
 
interface
 
uses
  Winapi.Windows, Winapi.Messages, System.SysUtils, System.Variants, System.Classes, Vcl.Graphics, Vcl.Controls,
  Vcl.Forms, Vcl.Dialogs, Vcl.StdCtrls, Vcl.ComCtrls;
 
type
  TForm1 = class(TForm)
    ProgressBar1: TProgressBar;
    lbPosition: TLabel;
    Button1: TButton;
    Memo1: TMemo;
    Label1: TLabel;
    procedure Button1Click(Sender: TObject);
  private
    { Private declarations }
    procedure MemoOnProgress(const ACurrent, ACount: Integer);
    procedure LabelOnProgress(const ACurrent, ACount: Integer);
    procedure ProgressBarOnProgress(const ACurrent, ACount: Integer);
 
    procedure MemoBeforeStart(const ACount: Integer);
    procedure LabelBeforeStart(const ACount: Integer);
    procedure ProgressBarBeforeStart(const ACount: Integer);
 
    procedure MemoOnFinished(Sender: TObject);
    procedure LabelOnFinished(Sender: TObject);
    procedure ProgressBarOnFinished(Sender: TObject);
  public
    { Public declarations }
  end;
 
var
  Form1: TForm1;
 
implementation
 
uses
  Unit2;
 
{$R *.dfm}
 
procedure TForm1.Button1Click(Sender: TObject);
var
  LHacerAlgo: THacerAlgo;
begin
  Button1.Enabled := False;
  LHacerAlgo := THacerAlgo.Create(500);
  try
    LHacerAlgo.BeforeStart(LabelBeforeStart);
    LHacerAlgo.BeforeStart(MemoBeforeStart);
    LHacerAlgo.BeforeStart(ProgressBarBeforeStart);
 
    LHacerAlgo.OnProgress(LabelOnProgress);
    LHacerAlgo.OnProgress(MemoOnProgress);
    LHacerAlgo.OnProgress(ProgressBarOnProgress);
 
    LHacerAlgo.OnFinished(LabelOnFinished);
    LHacerAlgo.OnFinished(MemoOnFinished);
    LHacerAlgo.OnFinished(ProgressBarOnFinished);
 
    LHacerAlgo.HacerAlgo;
  finally
    LHacerAlgo.Free;
    Button1.Enabled := True;
  end;
end;
 
procedure TForm1.LabelBeforeStart(const ACount: Integer);
begin
  Label1.Caption := Format('Vamos a procesar %d elementos...', [ACount]);
end;
 
procedure TForm1.LabelOnFinished(Sender: TObject);
begin
  Label1.Caption := 'Label se entero que termino el proceso!';
end;
 
procedure TForm1.LabelOnProgress(const ACurrent, ACount: Integer);
begin
  Label1.Caption := Format('Procesando: %d / %d', [ACurrent, ACount]);
end;
 
procedure TForm1.MemoBeforeStart(const ACount: Integer);
begin
  Memo1.Clear;
  Memo1.Lines.Add('Comenzo el proceso a las ' + DateTimeToStr(Now));
  Memo1.Lines.Add(EmptyStr);
end;
 
procedure TForm1.MemoOnFinished(Sender: TObject);
begin
  Memo1.Lines.Add(EmptyStr);
  Memo1.Lines.Add('Termino el proceso ' + DateTimeToStr(Now));
end;
 
procedure TForm1.MemoOnProgress(const ACurrent, ACount: Integer);
begin
  Memo1.Lines.Add(Format('%s -- Voy por el %d, me faltan %d', [DateTimeToStr(Now), ACurrent, ACount - ACurrent]));
end;
 
procedure TForm1.ProgressBarBeforeStart(const ACount: Integer);
begin
  ProgressBar1.Min := 0;
  ProgressBar1.Max := ACount;
  ProgressBar1.Position := 0;
end;
 
procedure TForm1.ProgressBarOnFinished(Sender: TObject);
begin
  lbPosition.Caption := 'Progress bar se entero que termino el proceso!';
end;
 
procedure TForm1.ProgressBarOnProgress(const ACurrent, ACount: Integer);
begin
  TThread.Synchronize(NIL, procedure
  begin
    lbPosition.Caption := IntToStr(ACurrent);
    ProgressBar1.Position := ACurrent;
    Application.ProcessMessages;
  end);
end;
 
end.

THacerAlgo:
 

delphi

unit Unit2;
 
interface
 
uses
  System.Classes, System.Generics.Collections;
 
type
  TOnProgress = procedure(const ACurrent, ACount: Integer) of object;
  TBeforeStart = procedure(const ACount: Integer) of object;
 
  TOnProgressEventsList = TList<TOnProgress>;
  TBeforeStartEventsList = TList<TBeforeStart>;
  TOnNotifyEventsList = TList<TNotifyEvent>;
 
  THacerAlgo = class
  private
    FCount: Integer;
    FOnProgressEventsList: TOnProgressEventsList;
    FBeforeStartEventsList: TBeforeStartEventsList;
    FOnCompletedEventsList: TOnNotifyEventsList;
  protected
    procedure NotifyOnProgress(const ACurrent: Integer); virtual;
    procedure NotifyOnBeforeStart; virtual;
    procedure NotifyOnCompleted; virtual;
  public
    constructor Create(const ACount: Integer);
    destructor Destroy; override;
    procedure HacerAlgo; overload;
    procedure HacerAlgo(const ACount: Integer); overload;
    procedure OnProgress(DoOnProgress: TOnProgress);
    procedure BeforeStart(DoBeforeStart: TBeforeStart);
    procedure OnFinished(DoOnFinished: TNotifyEvent);
    property Count: Integer read FCount;
  end;
 
implementation
 
{ THacerAlgo }
 
constructor THacerAlgo.Create(const ACount: Integer);
begin
  inherited Create;
  FOnProgressEventsList := TOnProgressEventsList.Create;
  FBeforeStartEventsList := TBeforeStartEventsList.Create;
  FOnCompletedEventsList := TOnNotifyEventsList.Create;
  FCount := ACount;
end;
 
destructor THacerAlgo.Destroy;
begin
  FOnProgressEventsList.Free;
  FOnCompletedEventsList.Free;
  FBeforeStartEventsList.Free;
  inherited Destroy;
end;
 
procedure THacerAlgo.HacerAlgo;
var
  LCurrent: Integer;
begin
  NotifyOnBeforeStart;
 
  for LCurrent := 0 to Count - 1 do
  begin
    { hacer algo }
      NotifyOnProgress(LCurrent);
  end;
 
  NotifyOnCompleted;
end;
 
procedure THacerAlgo.HacerAlgo(const ACount: Integer);
begin
  FCount := ACount;
  HacerAlgo;
end;
 
procedure THacerAlgo.NotifyOnBeforeStart;
var
  LBeforeStartEvent: TBeforeStart;
begin
  for LBeforeStartEvent in FBeforeStartEventsList do
    LBeforeStartEvent(Count);
end;
 
procedure THacerAlgo.NotifyOnCompleted;
var
  LOnCompleted: TNotifyEvent;
begin
  for LOnCompleted in FOnCompletedEventsList do
    LOnCompleted(Self);
end;
 
procedure THacerAlgo.NotifyOnProgress(const ACurrent: Integer);
var
  LOnProgressEvent: TOnProgress;
begin
  for LOnProgressEvent in FOnProgressEventsList do
    LOnProgressEvent(ACurrent, Count);
end;
 
procedure THacerAlgo.BeforeStart(DoBeforeStart: TBeforeStart);
begin
  FBeforeStartEventsList.Add(DoBeforeStart);
end;
 
procedure THacerAlgo.OnFinished(DoOnFinished: TNotifyEvent);
begin
  FOnCompletedEventsList.Add(DoOnFinished)
end;
 
procedure THacerAlgo.OnProgress(DoOnProgress: TOnProgress);
begin
  FOnProgressEventsList.Add(DoOnProgress)
end;
 
end.

Salida:

[Agustin Ortu]

Creo que modificando un poco el codigo anterior se podria agregar manejo de prioridades. Yo use estructura lista para almacenar los eventos que se deben procesar, pero se podria usar la que mas comodo le quede a cada uno

 

Siguiendo con la lista, si uno cambia los metodos que se usan paran "suscribirse" se podria agregar en distintas posiciones de la lista utilizando Insert en lugar de Add; de esta manera, un Insert(0, Evento) seria un evento de prioridad alta

 

Saludos

[Delphius]

Hace un tiempo expuse parte del modelo del patrón Observer que he diseñado para mis trabajos. No ha cambiado al día de la fecha, a pesar de haberme hecho tantas preguntas. No es tan diferente el diseño que tiene de lo que se ha planteado aquí.

 

Saludos,

[Agustin Ortu]

Uff largo para leer y masticar y menos ahora que ya tengo la cabeza medio quemada

 

En fin, la moraleja: Aprovechar y abusar de los eventos y tratar de que todo el procesamiento, calculo, o trabajo real pase dentro de los objetos que saben hacer ese proceso; los formularios y controles solamente sirven para pedir/mostrar datos, y disparar metodos de las clases: avisarles que empiecen, que paren y poco, poco mas

 

A la larga (no miuy lejana, en realidad) termina dando muchisimo redito a lo(s) desarrolladores

[AngelF]

¡Madre de Dios!

Agustín, muchas gracias por tu tiempo. Parece que no era tan tonto lo que pretendía.

De todas maneras me temo que para mi nivel de programación tu código me supera. No soy informático, no he estudiado nunca programación y he aprendido a base de foros y lo que escribo en delphi y lazarus. Soy ingeniero que hace cosillas de bases de datos y poco más.

 

Parece que a Delphius le has dado ideas para trabajar así que tu tiempo en enseñarnos va a ser bien aprovechado.

 

Muchas gracias.

[Agustin Ortu]

no he estudiado nunca programación y he aprendido a base de foros y lo que escribo en delphi y lazarus.

 

En esto somos identicos (bueno, casi, 2 años y medios de estudio universitario)

 

Igual es todo cuestion de practica, de a poco la cabeza se va abriendo; de ultima un poco de ejercicio muscular al cerebro mal no le viene nunca 

 

Saludos

[giulichajari]

Hace un tiempo expuse parte del modelo del patrón Observer que he diseñado para mis trabajos. No ha cambiado al día de la fecha, a pesar de haberme hecho tantas preguntas. No es tan diferente el diseño que tiene de lo que se ha planteado aquí.

 

Saludos,

Hola Delphius..veo todas tus implementacion de patrones aqui en el foro...son muy buenas..

Por cierto.. tienes los diagramas UML de todo eso? Pregunto si es posible programarlo sin diagramar, de hecho se que llegar a semejante codigo sin imagenes es imposible....

[Delphius]

Hola Delphius..veo todas tus implementacion de patrones aqui en el foro...son muy buenas..

Por cierto.. tienes los diagramas UML de todo eso? Pregunto si es posible programarlo sin diagramar, de hecho se que llegar a semejante codigo sin imagenes es imposible....

 

La verdad es que no tengo los diagramas de mis implementaciones.

Mis creaciones son fruto del estudio y análisis del tema. Tengo varias fuentes de consulta las que más consulto y son fundamentales:

* UML y Patrones. Craig Larman.

* Wikipedia

* OODesign

* Source Making

 

El Diagrama de mi implementación no variará de otro. Es sólo una aplicación del patrón. Y como tal, visto desde dicho patrón tiene un diseño definido. Justamente eso es lo que hace al patrón: definir una solución especifíca para un problem específico. Ergo: tiene un diseño específico, desde la perspectiva de UML. Por ejemplo, para el caso del patrón Observer lo que se nota es que existe una clase Sujeto que tiene una relación de agregación con otra que actúa base de Observador.  La clase que actúa de Sujeto tiene los métodos necesarios para registrar a los sujetos y para llevar a cabo las notificaciones necesarias. Por su parte las clases Observadores que heredan del Observador base implementarán sus métodos de respuesta al mensaje de notificación que el sujeto les emite.

 

Puedes ver el diagrama UML en wiki.

 

El diagrama puede "ampliarse" para ilustrar un diseño más "personalizado". Por ejemplo, en mi caso podría verse que mis clases Sujeto y Observador heredan de sus respectivas interfaces. Y también podría añadir al diagrama la relación de mi TAbstractSubject con TInterfacedList, y que ésta última es la que finalmente hace la relación de agregación con IAbstractObserver.

 

Lo importante es entender el concepto. Naturalmente que los diagramas ayudan, pero repito: uno puede darles los detalles necesarios según sus necesidades. La estructura básica y fundamental es la que puedes ver en los sitios fuentes que te dí. Cuando uno ya se hace la idea del patrón incluso la imagen UML ya ni es necesaria. Uno ya asimila que la clase Sujeto debe tener una lista, que los observadores implementen las respuestas, etc... y ni se pone a pensar en si tiene que trazar una flechita, o en poner el rombo en la relación de agregación... etc.

Al comienzo era muy meticuloso en los diagramas. En la medida en que iba estudiando los patrones cada vez me ha sido necesario dibujar menos. A la fecha sólo me siento a dibujar para ayudar a ordenar mis ideas y sólo lo necesario. No me pongo a hacer cientos...

 

Y cuando necesito dibujar, lo hago a mano. Me siento con el lápiz y el papel. A los que realmente necesito los llevo al mundo digital para formar la documentación "oficial".

 

Saludos,

[Delphius]

Uff largo para leer y masticar y menos ahora que ya tengo la cabeza medio quemada

 

En fin, la moraleja: Aprovechar y abusar de los eventos y tratar de que todo el procesamiento, calculo, o trabajo real pase dentro de los objetos que saben hacer ese proceso; los formularios y controles solamente sirven para pedir/mostrar datos, y disparar metodos de las clases: avisarles que empiecen, que paren y poco, poco mas

 

A la larga (no miuy lejana, en realidad) termina dando muchisimo redito a lo(s) desarrolladores

 

Asi es como debiera ser... en la práctica es otra cosa. ¡Cuántas veces nos vemos obligados a hacer unas mezclas que nos afecta la cohesión! Hay que recordar que la cohesión y el acoplamiento son necesarios, e inevitables. Van de la mano.

 

Estos tipos de relación entre interfaz-lógica/procesal se hace más complicado cuando ya no se trata de un diseño tradicional que sugiere 3 capas: lógico, interfaz, datos. En cuanto ya se vuelve de interés tener las capas de aplicación, presentación, dominio ya se hace más lioso el trabajo.

 

Y si, el perfil del diseñador es fundamental tenerlo. Ayuda mucho.

 

Y como dije, hay cosas inevitables. Por ejemplo hace unas semanas que estuve dando batalla a un diseño que me comía la cabeza... necesitaba ahorrarme código hasta cuadruplicado (salvo algunos detalles entre ellos), pero también un par de evaluaciones. Si me centraba en el ahorro de esos codigos repetibles, generaba evaluaciones innecesarias en otros lados... Y si centraba las evaluaciones, me condicionaba a estar repitiendo parte del código que se dedicada a tareas de procesamiento. Si sumaba todas las evaluaciones llegaba a una V(G) de 6 a 7. Y 7 es considerado el número mágico en el que uno debe prender la lamparita y revisar lo que tiene.

Y si considero que incluso el rediseño era necesario para evitar mover grandes estructuras de datos entre diferentes métodos para no provocar un error de memoria... puff. No hay cabeza que aguante. Te consume.

Esto nos lleva a que uno debe hacer aceptar ciertos compromisos.

Sea el camino que elija en algo se pierde.

 

Hay batallas que no necesariamente nos lleve a una respuesta definitiva o clara. Y esa es una lección que debemos aprender. En informática existe el gris.

 

¡Madre de Dios!

Agustín, muchas gracias por tu tiempo. Parece que no era tan tonto lo que pretendía.

De todas maneras me temo que para mi nivel de programación tu código me supera. No soy informático, no he estudiado nunca programación y he aprendido a base de foros y lo que escribo en delphi y lazarus. Soy ingeniero que hace cosillas de bases de datos y poco más.

 

Parece que a Delphius le has dado ideas para trabajar así que tu tiempo en enseñarnos va a ser bien aprovechado.

 

Muchas gracias.

 

En realidad la idea es una refrescura de un concepto en el que venía trabajando.

Tenía un diseño más elaborado... y complejo. Una serie de observadores encadenados... Es decir que un observador era a su vez un sujeto y notificaba a alguien de más "arriba". Y se estaba yendo de la mano. Rediseñé mi trabajo, y parte del problema se eliminó pero aún no había dedicado a estudiar en como haría la comunicación entre interfaz y la parte "procesal" adaptada al nuevo esquema.

En mi nuevo esquema procesal hay varios objetos interviniendo, operando, y hay info de interés que viene bien estar dando aviso de como va el trabajo. Justamente es lo que me estaba maquinando la cabeza hasta que vi la propuesta de Agustín con sus eventos OnBefore, OnProcess y OnFinish y la lamparita prendió.

 

No te sientas mal por si sientes que esto te supera. No temas. Las propuestas de Agustín como la mía es aprovechar el concepto de eventos. Tienen un potencial enorme. En resumen, e independientemente de la complejidad de nuestros diseños, todo se resume en dotar a las clases de interés de un mecanismo de publicación de avances o cambios que otros estén interesados.

Entonces tenemos una clase que hace algo, y otra que quiere ser avisada de eso. Entonces ambas deciden compartir un "protocolo de comunicación", para eso son los eventos. La clase que se dedica a "procesar" define el cuerpo (las estructuras) de los eventos que considera necesario para compartir los cambios y avisos. La clase que "escucha" los cambios va a implementar los métodos de respuesta para dichos eventos.

 

Eso es lo que propone el patrón Observador, únicamente que lo abstrae más. En lugar de asumir una relación 1-1, propone que sean varios los interesados en ser notificados. La clase Sujeto (la que procesa y notifica) registra en una lista a los observadores. Luego simplemente recorre la lista y les envía el mensaje de que algo ha cambiado/sucedido y les pasa por parámetro el dato que necesitan. Ya cada observador implementará el algoritmo adecuado para dar respuesta al aviso.

 

En el ejemplo de Agustín puedes ver el caso 1-1. Tiene una clase que define 3 eventos (uno para antes de empezar, en proceso y otra para cuando finaliza) y es la que centra el trabajo. Luego está el observador que es el form. En el form implemeta los algoritmos de respuesta para los 3 eventos.

 

Saludos,

[AngelF]

Sí, la idea general, el porqué de hacerlo así lo entiendo. Lo que se me escapa es el cómo, el código que desarrolla Agustín, que desde luego está varios escalones por encima de mi nivel.

Pero como bien decís, así se aprende, que leche.

 

Muy agradecido por compartir vuestros conocimientos y sobre todo, el tiempo que nos dedicáis.

[Delphius]

Sí, la idea general, el porqué de hacerlo así lo entiendo. Lo que se me escapa es el cómo, el código que desarrolla Agustín, que desde luego está varios escalones por encima de mi nivel.

Pero como bien decís, así se aprende, que leche.

 

Muy agradecido por compartir vuestros conocimientos y sobre todo, el tiempo que nos dedicáis.

 

No te minimices.

Lo más importante del código está en definir que tipos de datos se necesita notificar y en que momentos dispararlos. Como he dicho: se trata de pensar en un "protocolo" que tanto el proceso como el oyente sepan manejarlo.

Si te abruma el código de Agustín, puedes empezar leyendo en el foro de Manuales los conceptos. He dedicado un "capítulo" al tema de eventos y el sistema de notificaciones.

 

Saludos,

[AngelF]

Muy interesante.

 

Gracias.