Cómo codificar en el evento (incluso asignado) de un componente

[dec]

Hola,

A quien le pueda resultar interesante, aquí tienen una posible forma de ocultar propiedades, dictada por Neftali. En todo caso, Crandel, lo que propones funciona exactamente como esperaba. Muchísimas gracias a todos. De verdad.

[dec]

Hola,

Bueno, pues, he llamado al engendro TDecBrowser y pueden conseguirlo aquí mismo. Gracias de nuevo a todos.

[roman]

No sé, no sé. A mi como que me da más algo del estilo:

Código Delphi [-]
unit DecBrowser;

interface

uses
  OleCtrls, SHDocVw, ActiveX;

type
  TDecBrowser = class(TWebBrowser)
  protected
    procedure InvokeEvent(DispID: TDispID; var Params: TDispParams); override;
  end;

implementation

procedure TDecBrowser.InvokeEvent(DispID: TDispID; var Params: TDispParams);
begin
  inherited;

  if DispId = 250 then // 250 - OnBeforeNavigate2
  begin
    {
      Aquí tu código
    }
  end;
end;

end.

Si inherited se llama antes o después ya dependerá de tus necesidades específicas.

// Saludos

[[Crandel]]

Empezado por roman

No sé, no sé. A mi como que me da más algo del estilo:
...

Supuse desde un principio que en este tema no podía dejar de faltar la participación de Roman

Lo que comentas lo pense al prpicipio, pero el tema es que el método InvokeEvent es llamado muchas veces al parecer, lo cual se estaria llamando constantemente a nuestro método override, para no hacer nada.

Si la idea es capturar este único evento, lo haria con mi propuesta, si se quiere capturar varios más, lo haria a la forma recdomendada por roman.

[roman]

Empezado por Crandel

pero el tema es que el método InvokeEvent es llamado muchas veces al parecer, lo cual se estaria llamando constantemente a nuestro método override, para no hacer nada.

¿Y?

¿Te imaginas cuántas veces se llama a WndProc? Pero esto no es óbice para no redefinirlo de ser necesario incluso si el comportamiento añadido es muy poco.

Por otra parte, aunque es cuestión de puntos de vista, los métodos y/o propiedades de una clase no debieran esconderse (aun suponiendo que realmente se puede); la herencia de clases se supone que está para añadir funcionalidad no para quitarla.

// Saludos

[[Crandel]]

Empezado por roman

¿Te imaginas cuántas veces se llama a WndProc? Pero esto no es óbice para no redefinirlo de ser necesario incluso si el comportamiento añadido es muy poco.

Por supuesto, que no va haber diferencia ni de velocidad, ni otra cosa. Sólo me parecio mejor opción para un solo evento, además de parecerse más a la consigna "Cómo codificar en el evento (incluso asignado) de un componente".

Empezado por roman

aunque es cuestión de puntos de vista, los métodos y/o propiedades de una clase no debieran esconderse (aun suponiendo que realmente se puede); la herencia de clases se supone que está para añadir funcionalidad no para quitarla.

no hable de esconder ni de quitar nada, todo esta en su lugar.

[roman]

Empezado por Crandel

todo esta en su lugar.

En esto estoy de acuerdo. Yo lo estaba entendiendo mal.

// Saludos

[Neftali [Germán.Estévez]]

Empezado por roman

...los métodos y/o propiedades de una clase no debieran esconderse (aun suponiendo que realmente se puede); la herencia de clases se supone que está para añadir funcionalidad no para quitarla.

Ahí no estoy de acuerdo contigo Román, no creo que sea cuestión de puntos de vista (porque no creo que siempre se pueda hacer A o B), creo que es cuestión de necesidades (a veces necesitarás que esté y otras veces no).
Si necesito heredar de un componente y la propiedad Color (por decir una) no tiene sentido en mi componente heredado, no creo que haya que dejarla visible/accesible.
¿Qué pasa si esa propiedad altera el comportamiento de tu componente de una forma no deseada?
¿Añado código para inutilizarla? Pero estonces estaré añadiendo código para deshabilitar una propiedad que sí veo y tengo accesible, pero que no necesito... ¿raro no?

[dec]

Hola,

Bueno. Pues el componente está muy bien, o eso me parece, en cuanto a que puede resultar útil, pero, me encuentro con un problema que paso a explicar. Se trata de las acciones que pueden asociarse al componente.

Puede asociarse con el componente "DecBrowser" un componente "TActionList". No hay problema en hacerlo, y tampoco con el componente, es decir, que todo parece ir bien.

El problema está en quitar el componente de un formulario en tiempo de diseño. Añádase en un formulario vació el componente "DecBrowser"; añádase también un "TActionList" al formulario; asígnese este último componente a la propiedad "Acciones" del "DecBrowser"; quítese del formulario ahora el "TActionList", y, a continuación, trátese de quitar el componente "DecBrowser" del formulario...

Perdón por las "violaciones de acceso", "errores abstractos" y demás. No era mi intención, se lo juro. Estoy probando cosas. Por ejemplo, si a la hora de crear la variable que contendrá la propiedad "Acciones" hago algo así:

Código Delphi [-]
   constructor TDecBrowser.Create(AOwner: TComponent);
   begin
     inherited Create(AOwner);
     FEnlaces := TStringList.Create;
     FAcciones := TActionList.Create(Forms.Application); // Aquí
     inherited OnBeforeNavigate2 := ComprobarEnlaces;
   end;

En lugar de algo como esto otro:

Código Delphi [-]
   constructor TDecBrowser.Create(AOwner: TComponent);
   begin
     inherited Create(AOwner);
     FEnlaces := TStringList.Create;
     FAcciones := TActionList.Create(Self); // Aquí
     inherited OnBeforeNavigate2 := ComprobarEnlaces;
   end;

La cosa parece pintar mejor, sin embargo, aún no he dado con la solución para el problema que he comentado arriba. Sigo en ello, a ver si soy capaz. Cualquier ayuda será bienvenida. Por cierto, en el código del componente actualmente hay algo como esto:

Código Delphi [-]
   property Acciones: TActionList read FAcciones write FAcciones;

Y lo he cambiado por algo así:

Código Delphi [-]
  property Acciones: TActionList read GetAcciones write SetAcciones;

Con sus correspondientes métodos:

Código Delphi [-]
  // Devolvemos la lista de acciones asociada.
  //
  function TDecBrowser.GetAcciones: TActionList;
  begin
    Result := FAcciones;
  end;
  
  // Establecemos la lista de acciones.
  //
  procedure TDecBrowser.SetAcciones(value: TActionList);
  begin
    FAcciones := value;
  end;

Pero, como pueden ver, son algo superfluos los métodos de arriba, puesto que para ese viaje no hacían falta tantas alforjas, como suele decirse. Pero, es que esto otro, aunque compilar compila, no funciona:

Código Delphi [-]
  // Establecemos la lista de acciones.
  //
  procedure TDecBrowser.SetAcciones(value: TActionList);
  begin
    FAcciones.Assign(value); // ni así
    FAcciones.Assign(TPersistent(value)); // ni así tampoco
  end;

Me aparece tal que este error:

---------------------------
Error
---------------------------
Cannot assign a TActionList to a TActionList.
---------------------------
OK
---------------------------

[roman]

Empezado por Neftali

¿Qué pasa si esa propiedad altera el comportamiento de tu componente de una forma no deseada?

Entonces quizá no estés heredando de la clase correcta.

Al hacer este tipo de manipulaciones rompes el polimorfismo. Si tienes una clase base A, cualquier tratamiento genérico sobre un conjunto de As presupone que todos los descendientes se comportarán como A, al menos en lo que el contrato de A establece.

// Saludos