Evento nuevo en objeto

LucianoRey · #1 01-09-2004

Hola, espero me puedan ayudar, como puedo agregar un evento a un componente, es decir, lo que quiero es crear un mensaje de usuario, eso mas o menos lo se hacer(creo), y quiero que ese mensaje sea un evento de mis componentes, mi idea es que por medio de valores que yo mande en wParam y lParam, mis objetos respondan a ese evento segun estos valores, por ejemplo con dos combos, el primero se llena por default pero el segundo depende de el primero y lo que quiero es que cuando le den click al primer combo yo pueda mandar un mensaje con wParam y lParam y que el segundo combo en su evento "Mensaje de usuario" responda segun lo amerite, lo trate de hacer atrapando en la forma un mensaje de usuario pero no me gusto porque tengo que decirle a quien le mando mi mensaje, ej. combo-envia mensaje, forma-toma el mensaje y dependiendo de sus valores, ejecuta un evento de X componente, por eso me gustaria saber como implemento un evento a un componente, de antemano gracias por su ayuda, saludos.

roman · #2 01-09-2004

Pues simplemente declaras una propiedad en el objeto que recibe el mensaje del tipo que desees para tu evento. Lo más sencillo:

Código Delphi [-]type
  TMiSegundoCombo = class(...)
  private
    FMiEvento: TNotifyEvent;

  public
    property MiEvento: TNotifyEvent read FMiEvento write FMiEvento
  end;

Cuando recibas el mensaje llamas al evento:

Código Delphi [-]if Assigned(FMiEvento) then FMiEvento(Self);

Un evento es una propiedad como cualquier otra salvo porque su tipo de datos es un método. Como en:

Código Delphi [-]type
  TNotifyEvent = procedure (Sender: TObject) of object;

Si te conviene puedes definir el tipo de datos con más parámetros (o menos pues el consabido Sender no es estrictamente necesario):

Por otra parte, ¿estás seguro de requerir un mensaje? Para que el primer combo mande un mensaje al segundo debe conocer el 'handle' de éste y si lo conoces entonces muy posiblemente conces al combo e sí de maner que por qué no poner el combo destinatario como propiedad del primero, si queires protegida para que no pueda accederse desde fuera.

// Saludos

LucianoRey · #3 01-09-2004

Gracias por la respuesta, y se me olvido decir que este evento lo quiero para mi forma y los componentes dentro de ella, la idea es que la forma responda a este evento, por medio del mensaje de algun componente y lo reenvie (la forma) a sus hijos (componentes) para que responda quien tenga que responder a este evento segun los valores que sean enviados, por ejemplo el caso de los combos, el primer combo al evento Onclick manda un mensaje al padre (en este caso la forma) y el padre lo reenvia a sus hijos, lo capta el segundo combo este hace lo que tenga que hacer y asi con cada componente, ¡ah! en cada "evento nuevo" de los componentes, quiero poner la condicion segun sea el caso:

Código:

 if wparam=1 then
   if lParam=1 then
	  instrucciones.....
   elseif lParam=2 then
	  instrucciones

algo asi, de esta forma no me importaria conocer a que componentes lo tengo que enviar o quien envia solo se envia y responde quien tenga que hacerlo, bueno es algo que aprendi y me gustaria usarlo en delphi, pero necesitaba un nuevo evento en cada componente para hacerlo y no sabia como hacerlo estoy iniciando en este negocio, pero si hay una mejor forma acepto sugerencias, saludos y otra vez gracias, la finalidad de esto es poder estandarizar componentes que yo se que me van a servir despues y que nada mas tenga que pegarlos y si acaso mandarle algun parametro, claro que sea parejo para todos, otra vez gracias.

[Lepe] · #4 02-09-2004

La respuesta de Roman es Correctísima (como siempre), quizás este ejemplo te aclare algo más:
El ejemplo que pongo a continuacion, es de un CheckListBox que tiene que informar a una ventana llamada FormDestino cuando se hace click en un elemento del CheckListBox.

Código Delphi [-]// creo mi evento especifico con los parametros que me interesa
  type TNotifyCheckClicks  = procedure(FormClicked: Integer; const Value: integer) of object;

type  Form_del_Checklistbox = class(Tform)
  private
    FInformarClicks: TNotifyCheckClicks;

  public
    { Public declarations }
    property InformarClicks:TNotifyCheckClicks read FInformarClicks Write FinformarClicks default nil;

implementation

procedure Tform_del_Checklistbox.CheckListboxClicks(....)
begin
// cuando se hace clic en un elemento, lanzo mi Evento
    if Assigned(FInformarClicks) then
    begin
      FInformarClicks(Self.Parent.Tag,i);

      Application.ProcessMessages;
    end;
end;

Ahora solo queda recoger el evento.

Código Delphi [-]
procedure  FormDestino.FormDestinoCreate(...)
begin
  Form_del_checklistbox.InformarClicks := SetHechoClick;
end;

// por supuesto SetHechoClick tiene que tener los mismos parametros que un   TNotifyCheckClicks
procedure FormDestino.SetHechoClick(FormClicked: Integer; const chklbIndex: integer);

begin
// Y listo, este procedimento en FormDestino, se ejecutará cuando se hace
// un click en el CheckListBox, recibiendo los parametros que a mi me interesa.
end;

Eso de que el padre (FormDestino) reenvie el mensaje a sus hijos (controles dentro de FormDestino), no lo veo claro. Para cada componente que uses, tendrías que crearle el evento TNotifyCheckClicks, y es bastante trabajo. Creo que es mejor centralizar todo el trabajo de los hijos en el procedimiento SetHechoClick.

Saludos

Saludos

LucianoRey · #5 02-09-2004

Asi es Lepe, como ya me estoy adentrando mas en esto, ya me di cuenta que para lo que quiero es mejor crear mis componentes e incluir entre sus propiedades "mi evento", el ejemplo que me pones ( y no es por presumir, estoy aprendiendo ) ya lo habia hecho, pero no me gusto porque la idea es que.. bueno antes he de decir trabaje con Centura como lenguaje de programación y en este creaba un evento de usuario, este evento lo podia llamar en cualquier componente y lo que hacia era definirlo en los componentes que lo iban a utilizar(casi siempre eran todos incluyendo la Forma contenedora), dentro de este evento siempre manejaba wParam y lParam y por ejemplo si habia que limpiar los edit, combos o grid's que tuviera, le picaba al boton limpiar, este boton en su evento "MUsuario", enviaba un mensaje ej. SendMessage(Parent(HandleBotonLimpiar), MUsuario, 0,0) el 0,0 eran wParam y lParam respectivamente, este mensaje(MUsuario) era enviado a la Forma que contenia dichos componentes, esta a su vez cada que recibia un mensaje de este tipo lo reenviaba a todos sus componentes, algo asi como SenMessage( Child(HandleForma), MUsuario, wParam, lParam), y en mis componentes, como ya tenia definido el evento MUsuario, en cada uno tenia un codigo parecido a esto:

Código:

 
  On_MUsuario
	 if wParam =1
		if lParam = 1
		   Myvalue:='' // 
		elseif lParam=2
		   MyValue:=vArray[1]

en este caso yo le decia si es 1 limpia sino pon el valor del array correspondiente, esto a la hora de codificar me ahorraba bastante tiempo, porque solo copiaba el mismo codigo para todos mis componentes, y por ejemplo si habia algun cambio en la estructura de mi pantalla, solo borraba o creaba otro componente sin preocuparme por cambiar codigo en cualquier otro lado, ....regresando a lo primero lo que quiero, es eso mismo no tener que depender de los nombre de componentes en el codigo, es decir mi forma y sus componentes con su "evento usuario", si algun componente afecta el contenido de los demas pues envia un mensaje "evento usuario" a la forma y esta lo manda a todos los componentes y cada componente en su "evento usuario", tendra el codigo que tenga que ejecutar, si no debe responder pues no tendra nada, en el mismo caso que referia, ya tengo todos mis componentes con sus eventos "evento usuario", suponiendo que tengo una forma con un dbgrid donde muestro n registros y seleccionan uno para su edición ó quieren hacer un alta, bueno pues voy a la forma de registro y en el evento "evento usuario" de todos mis componentes donde voy a capturar la información, quiero decirle :
A mis componentes si lParam es 1 pues carga tu valor del array de campos, si es 2 quedate como estas, pero esto seria en cada "evento usuario" del componente y
A mi Forma si lParam es 1 tu caption sera "alta", si es 2 "modificación", si es 3 "Consulta", la primera vez que haga esto, se que va a ser bastante trabajo, pero las demas solo tendria que pegar mis componentes y ya, para estandarizar, bueno la inquietud de esto es porque voy a trabajar con SqlServer y quiero llevarme a mis pantallas los datos de mis registros pero tratando de utilizar el menos ancho de banda posible, bueno estoy tratando de usar lo menos posible componentes db que siempre estan conectados a los datos, espero ir bien en esto si no ustedes me diran, la verdad me han ayudado bastante, bueno ya me extendi, saludos y gracias por sus respuestas.

roman · #6 03-09-2004

Pues tal como lo describes puedes hacerlo prácticamente tal cual con Delphi. De hecho me he perdido un poco en la explicación y ya no sé si lo tienes o no resuelto.

Algunas ideas:

Como creo que ya has observado tendrás que crear componentes (o descendientes de componentes) para poder manejar los mensajes. El punto es que Delphi traduce los mensaje tipo Windows (los que envías con SendMessage) en eventos pero no implementa uno genérico que tú puedas definir durante el diseño.

Según he entendido, tú idea a grandes rasgos es como sigue:

Cita:

Ante determinada acción sobre algún control, éste envía un mensaje al formulario quien a su vez lo transmite a todas las componentes.

Cada componente puede o no implementar código para manejar el mensaje y, de hacerlo, actuará de acuerdo al valor de los parámetros.

El problema aquí es que cada componente tendrá que manejar un doble case:

Código Delphi [-]case WParam of
  1:
    case LParam of
      1: ... ;
      2: ... ;
      ...
    end;

  2:
    case LParam of
      1: ... ;
      2: ... ;
      ...
    end;

    ...
end;

que para mi gusto hace el código muy ilegible y difícil de mantener aun cuando no todas las componentes implementen todas las etiquetas.

Quiero suponer que posiblemente WParam lo usas para el tipo de acción a realizar (limpiar, cargar, guardar, etc) y LParam afecta el cómo se realiza la acción.

Lo primero entonces es separar las acciones en distintos mensajes:

Código Delphi [-]const
  CM_CLEAN = WM_USER + 1;
  CM_LOAD = WM_USER + 2;
  CM_SAVE = WM_USER + 3;
  ...

y crear manejadores para cada mensaje:

Código Delphi [-]procedure CMClean(Msg: TMessage); message CM_CLEAN;
procedure CMLoad(Msg: TMessage); message CM_LOAD;
procedure CMSave(Msg: TMessage); message CM_SAVE;
...

Las componentes que no manejen una acción en particular simplemente no implementan el correspondiente manejador.

Lo siguiente es convertir estos mesajes en eventos:

Código Delphi [-]type
  TCleanEvent = procedure(params, var Proceed: Boolean);
  TLoadEvent = procedure(params, var Proceed: Boolean);
  SaveEvent =  procedure(params, var Proceed: Boolean);
  ...

¿Por qué en eventos?

Cada componente podría manejar de alguna manera estándar un determinado mensaje pero al convertirlo en evento se da la oportunidad al programador de modificar el comportamiento en tiempo de diseño.

El parámetro Proceed quizá no te sea necesario pero ante algo tan general como lo que planteas yo lo pondría para poder parar el mensaje de ser necesario. La idea es:

Una componente envía uno de estos mensajes al formulario quien normalmente lo pasará a todas sus componentes. El programador puede detener la transmisión del mensaje en el correspondiente evento del formulario poniendo Proceed := false si por alguna circunstancia ve que no conviene transmitirlo. Así mismo, cuando una componente recibe un mensaje, puede determinar no pasarlo a los que le siguen.

Esto es similar, por ejemplo, a cuando intentas cerrar una aplicación MDI como Word. El sistema manda el mensaje WM_CLOSE a la ventana principal quien a su vez lo manda a todos los documentos. Si alguna de éstos tiene cambios sin guardar presenta un mensaje al usuario. Si éste decide cancelar entonces el mensaje WM_CLOSE ya no se sigue difundiendo.

params en las declaraciones de arriba significa cualesquiera parámetros que consideres conveniente para la acción. Podrías usar WParam y LParam pero esto te deja un código poco legible. Considera que un mensaje como WM_KEYDOWN, Delphi lo connvierte a fin de cuentas en el evento OnKeyDown cuyos parámetros son mucho más entendibles.

Ahora concretemos.

Comencemos por el formulario, quien debe encargarse de transmitir los mensajes a todas sus componentes:

Código Delphi [-]interface

type
  TXForm = class(TForm)
  private
    FOnClean: TCleanEvent;
    FOnLoad: TLoadEvent;
    FOnSave: TSaveEvent;

    procedure CMClean(Msg: TMessage); message CM_CLEAN;
    procedure CMLoad(Msg: TMessage); message CM_LOAD;
    procedure CMSave(Msg: TMessage); message CM_SAVE;

  protected
    procedure BroadcastMessage(Msg: TMessage);

  published
    property OnClean: TCleanEvent read FOnClean write FOnClean;
    property OnLoad: TLoadEvent read FOnLoad write FOnLoad;
    property OnSave: SaveEvent read FOnSave write FOnSave;
  end;

implementation

{
  En cada manejador, el formulario llama al correspondiente evento
  y transmite el mensaje sólo si Proceed es true después de la llamada
}

procedure TXForm.CMClean(Msg: TMessage); message CM_CLEAN;
var
  Proceed: Boolean;

begin
  Proceed := true;

  if Assigned(FOnClean) then FOnClean(params, Proceed);
  if Proceed then BroadcastMessage(Msg);
end;

procedure TXForm.CM_Load(Msg: TMessage); message CM_LOAD;
var
  Proceed: Boolean;

begin
  Proceed := true;

  if Assigned(FOnLoad) then FOnLoad(params, Proceed);
  if Proceed then BroadcastMessage(Msg);
end;

procedure TXForm.CM_SAVE(Msg: TMessage); message CM_SAVE;
var
  Proceed: Boolean;

begin
  Proceed := true;

  if Assigned(FOnSave) then FOnSave(params, Proceed);
  if Proceed then BroadcastMessage(Msg);
end;

{
  BroadcastMessage transmite el mensaje a cada control.
  Si un control devuelve false entonce se detiene la
  transmisión.
}
procedure TXForm.BroadcastMessage(Msg: TMessage);
var
  Proceed: Boolean;
  Control: TControl;
  I: Integer;

begin
  Proceed := true;

  for I := 0 to ComponentCount - 1 do
    if Components[i] is TControl then
    begin
      Control := TControl(Components[i]);
      Proceed := Boolean(Control.Perform(Msg.Msg, Msg.WParam, Msg.LParam));
      if not Proceed then break;
    end;
end;

Finalmente vemos como sería el caso de una componente:

Código Delphi [-]interface

type
  TXDBGrid = class(TTDBGrid)
  private
    FOnClean: TCleanEvent;
    FOnLoad: TLoadEvent;
    FOnSave: TSaveEvent;

    procedure CMClean(Msg: TMessage); message CM_CLEAN;
    procedure CMLoad(Msg: TMessage); message CM_LOAD;
    procedure CMSave(Msg: TMessage); message CM_SAVE;

  published
    property OnClean: TCleanEvent read FOnClean write FOnClean;
    property OnLoad: TLoadEvent read FOnLoad write FOnLoad;
    property OnSave: TSaveEvent read FOnSave write FOnSave;
  end;

implementation

{
  Cada manejador llama al evento correspondiente. Si luego de la
  llamada Proceed es false asignamos 0 a Msg.Result a fin de que
  la llamada a Perform por parte del formulario devuelva 0 (false)
  y se detenga la transmisión del mensaje a los otros controles.
}
procedure TXDBGrid.CMClean(Msg: TMessage);
var
  Proceed: Boolean;

begin
  Proceed := true;
  if Assigned(FOnClean) then FOnClean(params, Proceed);
  Msg.Result := Integer(Proceed);
end;

...

Desde luego queda la sensación de que estamos repitiendo todo lo que hace la VCL de Delphi con los mensajes de Windows pero bueno, es el resultado de querer algo tan genérico.

// Saludos

jachguate · #7 03-09-2004

Este, apreciado Román, es un artículo digno de una revista o de un buen libro de programación en Delphi.

Te felicito por él, que será un verdadero pan para usuarios que quieren introducirse a la programación de componentes que responden a mensajes (del sistema o definidos por tu programa).

Hasta luego.

roman · #8 03-09-2004

Cita:

Empezado por jachguate

será un verdadero pan para usuarios que quieren introducirse a la programación de componentes que responden a mensajes (del sistema o definidos por tu programa).

Mmmm... sí... quizás.

No me convence.

Realmente creo que el compañero LucianoRey debería repensar un poco su objetivo. Entiendo su necesidad de reusar código pero no me parece adecuado algo así tan general. Creo que a la larga es contraproducente. Realmente es muy difícil de saber sin más detalles de lo que realmente desea. Con la información que nos da la situación es muy confusa; en verdad me cuesta trabajo ver qué relación hay en todo esto con aligerar el ancho de banda para consultas a un servidor SQL Server.

Creo que es demasiado abarcar. Aquello de usar los mismos mensajes para determinar si el formulario en sí dice 'alta', 'modificación' o 'consulta' no parece tener nada que ver con el comportamiento que otras componentes puedan tener ante los mensajes. Y no sólo eso; aunque no lo dice, suena a que va a utilizar el mismo formulario para por lo menos tres cosas distintas lo que seguramente implicará un uso extenso de condicionales para mostrar u ocultar determinados controles dependiendo del 'mensaje' que se le mande en lugar de usar herencia visual que deja un código mucho más prolijo.

En fin, sin más detalles es imposible decir casi nada sensato.

// Saludos

jachguate · #9 03-09-2004

Cita:

Empezado por roman

Mmmm... sí... quizás.

mmmm... si. seguro.

Cita:

Empezado por roman

Entiendo su necesidad de reusar código pero no me parece adecuado algo así tan general. Creo que a la larga es contraproducente. Realmente es muy difícil de saber sin más detalles de lo que realmente desea.

Tenes toda la razón sobre la falta de detalles. Además el estilo de redacción, con todo en un parrafo hace mas dificil captar las ideas..

Pero eso no resta calidad al artículo... al contrario, le añade un plus.

Con respecto de la idea de reusar código... creo que podria valer la pena en algunos casos, pero habrá que evaluar siempre.

Cita:

Empezado por roman

me cuesta trabajo ver qué relación hay en todo esto con aligerar el ancho de banda para consultas a un servidor SQL Server.

Pues a mi no me ha costado tanto!.
No hay relación alguna!.

Cita:

Empezado por roman

en lugar de usar herencia visual que deja un código mucho más prolijo.

Pienso que una combinación de ambas técnicas podria ser muy poderosa! (sigue dependiendo, claro...

)

Cita:

Empezado por roman

En fin, sin más detalles es imposible decir casi nada sensato.

Si.. mejor nos callamos la boca..

Hasta luego.

roman · #10 03-09-2004

Cita:

Empezado por jachguate

Si.. mejor nos callamos la boca..

¡Hombre! No hay que ser tan drásticos

¿Cómo callarme esta gran duda que tengo?

¿Qué diantres es Centura?

En mi vida había oído hablar de ese lenguaje

jachguate · #11 03-09-2004

Cita:

Empezado por roman

¿Qué diantres es Centura?

Pues no se.. pero seguro que no tiene herencia visual..

LucianoRey · #12 03-09-2004

Bueno, perdón por la respuesta tan lenta pero con esto de los horarios, mientras yo duermo, ustedes trabajan, que bueno encontrar gente como ustedes

.

1.- De acuerdo con jachguate, "artículo digno de una revista o de un buen libro de programación en Delphi" , aunque yo no tenga tanta experiencia en esto, ni sea como ustedes de extraordinario.

2.- Centura es uno de tantos lenguajes que han pasado por aqui y la verdad si, menos robusto que Delphi, si tenia herencia visual y en el caso que planteo la definición de este evento era menos complicada, lo definiamos como una constante y ya lo podiamos usar en cualquier componente, aca la diferencia es que no habia un inspector con propiedades y eventos, los eventos los teniamos que llamar escribiendolos, bueno de repente ya no habia soporte en nuestro pais y lo tuvimos que dejar.

3.- Si, la idea es la que tiene Roman, reusar codigo, pero como dije antes estoy en ese proceso interminable del aprendizaje, y con esos consejos pues si lo cambio a lo que ponen como ejemplo. Bueno aqui expongo lo que deseo y lo que hacia en Centura, para aclarar un poco, aunque creo ya lo hicierón ustedes:

Si nos pedian una aplicación, en la parte de actualización, usabamos la misma pantalla para alta, modificación y consulta, antes de entrar a esta estaba la que contenia el grid con la lista de registros en la base y sobre esta lo clasico, doble click al renglón-modificacion, boton-alta y boton consulta, que nos llevaba a la del registro completo, como parametros mandabamos:

- boton cambio ó consulta = un arreglo con los datos del registro seleccionado, boton alta = un arreglo vacio,

- una bandera para indicar si era alta ó modificación,

- una bandera para indicar si era consulta,

- y un arreglo con el mismo numero de elementos del registro seleccionado, pero en blanco.

Ahora, en la forma del registro completo, todos nuestros componentes tenian un evento "Usuario", que mas bien era un mensaje, bueno al llegar a esta forma, habia un evento CreateComplete, que nos indicaba cuando la forma y todos sus componentes ya se habian creado, dentro de este evento enviabamos este mensaje-evento con wParam=X y lParam=X, a todos los componentes incluidos en la forma, cada componente en su evento "Usuario", tenia un codigo que en efecto era :

Código:

   if wParam = 0
	  Myvalue=ArrayIn[0]
	  if bConsulta
		 Enable:=False
   elseif wParam=2
	  ArrayOut[0]:=MyValue
	  vCambio:=(ArrayIn[0]=ArrayOut[0])
   elseif wParam=3
	  MyValue:=''
   if wParam = 0//esto en el caso de botones como inicializar ó grabar
	 if bConsulta
	   Hide:=True

y algunos mas, con esto cuando entrabas a la forma se enviaba el mensaje 0 y se asignaba en cada componente su valor del registro(de la tablla), si el usuario cambiaba algun(os) dato(s) de la forma y se arrepentia de ello tenia un boton Inicializar que al darle click enviaba el mensaje "Usuario" con 0 a la Forma y esta al recibir el mensaje lo reenviaba a todos sus componentes, esto como ven volvia a poner los valores iniciales y si ademas era consulta deshabilita el componente, si el usuario queria limpiar todos los campos tenia un boton Limpiar que al darle click enviaba el mensaje "Usuario" con 3, si queria grabar el registro al darle click al boton Grabar enviaba el mensaje "Usuario" con 2, esto comparaba el valor inicial del componente con el actual, si no eran iguales entonces tenia caso grabar el registro, en el caso de consultas los botones de Grabar, Inicializar ó cualquier otro que sobrara los desapareciamos de la pantalla, bueno espero haber sido mas claro esta vez.

El seguimiento de estos mensajes era como sigue:

Forma Inicial - si me llega un evento "Usuario", mensaje a hijos(componentes)

Componente - si me llega un evento "Usuario"(siempre del padre), ejecuto acciones si es necesario

Componente(acción) - si mi comportamiento cambia mi entorno, mensaje a mi Padre(Forma)

En cuanto al ancho de banda con Sql, estaba con la idea (falsa creo), de que usando dbEdit's y dblookupcombo's, mantenia la conexión viva mientras estaba en mi pantalla de modificación ó consulta, por eso la inquietud, me dije, "bueno, mete tus campos a un arreglo, ese arreglo lo mandas a la pantalla de edición y ahi por medio de un evento Usuario lo haces como antes, con eso en lo que consultan ó cambian datos, sueltas la conexión y listo", y no, lo que tengo en mi pantalla es el cache de lo que me trae del servidor, bueno disculpen mi ignorancia, leyendo estos foros y Delphi estoy aprendiendo mas, saludos y otra vez gracias por sus respuestas.

P.D. Me han de disculpar la ortografia pero estoy tan acostumbrado a escribir con mayuscula y sin acentos, que no me sale, pero igual, un curso de ortografia no me caera mal.

LucianoRey · #13 04-09-2004

Mil gracias por todo, ahora voy a mi casa, regreso hasta el lunes pero ya les platicare lo que haga en mi casa, con las sugerencias que me han dado, esto porque en mi casa no tengo internet, estoy por hacer un sistema para un area de programacion y presupuesto, donde capturan una serie de datos respecto a eventos artisticos y culturales que tienen museos, escuelas, teatros, etc., cuantos piensan hacer, cuanta gente creen que va a asistir, despues, cada mes van a alimentar con lo que hayan hecho hasta el momento y sobre eso generar estadisticas, al año los resultados de las metas programadas con lo cumplido, asi que tengo mucho trabajo y muchas cosas que aplicar, saludos y que la pasen bien.

jachguate · #14 04-09-2004

Creo que simplemente estas retorciendo todo... quizas en Centura esa era la mejor forma de hacerlo, pero antes de tratar de seguir trabajando sobre la misma idea, te recomiendo que revises y trates de comprender la forma que nos sugiere delphi.

Puede ser con controles dbAware, que ya se encargan en buena parte de todo ese rollo. O puede ser con controles no dbAware, pero desde otra perspectiva. Por ejemplo, derivando los que te sirvan comunmente, y haciendo que respondan a alguna Interfaz, que permita al formulario realizar las mismas operaciones... pero sin el envio de mensajes del sistema, sino con una representación mas orientada a objetos.

En fin, habrian muchas otras formas de enfrentarlo, en el caso de controles no dbAware.

Hasta luego.