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

[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

[jachguate]

Dec: Es la primera vez que leo este hilo, aún cuando lo visité alguna vez en la semana, no contaba con el tiempo para revisarlo completo. Lo que no termino de entender es, para que creas una instancia de TActionList, si al parecer, luego le asignarás un puntero a la propiedad, a otro TActionList, creado, manejado y destruido por la forma (o por un tercero).

Si lo único que se necesita es mantener una referencia a un ActionList, no hará falta crear o destruir uno al momento de crear/destruir la instancia de TDecWebBrowser y si el mecanismo de notificación que ya has implementado, que es la manera estándar de "desconectar" componentes con relaciones horizontales.

Si por el contrario, es tu WebBrowser quien crea la lista de acciones, no hará falta notificar, pues será el propio componente el que se encargue de crearla/destruirla, y el usuario del componente, cuando mucho, podrá añadir/eliminar elementos a este ActionList. Si ese es el caso, entonces proteges el miembro de la clase con métodos de asignación de la propiedad:

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

procedure TDecWebBrowser.SetAcciones(value : TActionList);

begin
  //no hacemos que nuestro miembro apunte a value, lo "procesamos"
  //de otra forma, sea asignandolo directamente, copiando las acciones, 
  //o de la manera que convenga a nuestros intereses.
  FAcciones.Assign(value);
end;

Hasta luego.

[andres1569]

Empezado por roman

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.

Recuerdo un debate en estos foros hace muuucho tiempo sobre un tema parecido (Román también estabas por allí, )

En este caso concreto no parece un problema enmascarar una propiedad (el método OnBeforeActivate) puesto que es para ampliar su comportamiento, se ofrece al usuario del componente la misma funcionalidad que tenía en el ancestro, incluso con el mismo nombre para el evento (según el código que ha puesto Crandel).

Lo que no tengo muy claro (no lo he probado pero supongo que fallará), es qué pasaría si accediéramos polimórficamente a varios objetos TWebBrowser, entre ellos un TDecWebBrowser, para asignar su evento OnBeforeActivate, algo así:

Código Delphi [-]
for i:=0 to ComponentCount - 1 do
  if Components[i] is TWebBrowser then
     TWebBrowser(Components[i]).BeforeActivate := MiMetodo;

Al llegar al componente de tipo TDecWebBrowser, ¿se modificaría el evento redefinido o el correspondiente al ancestro? Me inclino por esto segundo, no sé si alguien ha hecho sus pruebas al respecto.

Quizás esa sea una de las pegas de enmascarar una propiedad / método, que se está induciendo a un posible error.

Saludos

[dec]

Hola,

Empezado por Juan Antonio

Dec: Es la primera vez que leo este hilo, aún cuando lo visité alguna vez en la semana, no contaba con el tiempo para revisarlo completo. Lo que no termino de entender es, para que creas una instancia de TActionList, si al parecer, luego le asignarás un puntero a la propiedad, a otro TActionList, creado, manejado y destruido por la forma (o por un tercero).

Bueno. Se ha hecho eso no porque yo vea que es la mejor solución, sino porque se trataba de solucionar un problema... puede que no de la mejor manera, pero, verás ahora porqué digo esto.

Empezado por Juan Antonio

Si lo único que se necesita es mantener una referencia a un ActionList, no hará falta crear o destruir uno al momento de crear/destruir la instancia de TDecWebBrowser y si el mecanismo de notificación que ya has implementado, que es la manera estándar de "desconectar" componentes con relaciones horizontales.

Pues es el caso que haciéndolo de ese modo no funciona (Acabo de probarlo de nuevo). Lo he dicho más arriba. El problema se presenta si sitúas en un formulario un "TDecBrowser" y un "TActionList". Acto seguido asignas a la propiedad "Acciones" del "TDecBrowser" el "TActionList" y aun después quitas del formulario el "TActionList"... "violaciones de acceso" variadas e incluso la necesidad (si no le has cogido el truco, y aún así...) de reiniciar Delphi.

Empezado por Juan Antonio

Si por el contrario, es tu WebBrowser quien crea la lista de acciones, no hará falta notificar, pues será el propio componente el que se encargue de crearla/destruirla, y el usuario del componente, cuando mucho, podrá añadir/eliminar elementos a este ActionList. Si ese es el caso, entonces proteges el miembro de la clase con métodos de asignación de la propiedad: (...)

No se trata de eso, es decir, no veo la necesidad de que el "TDecBrowser" maneje internamente las acciones... para eso está ya el componente "TAcionList". Por cierto, trata de localizar un componente en la VCL (y en la JVCL también) que cuente con una propiedad de tipo "TActionList"... yo no he podido encontrarlo antes, cuando lo he intentado para tratar de fijarme cómo hacía para torear con esa propiedad.

Pero, me parece que comienzo a desvariar... Gracias de nuevo a todos.

[roman]

Empezado por dec

Pues es el caso que haciéndolo de ese modo no funciona (Acabo de probarlo de nuevo). Lo he dicho más arriba. El problema se presenta si sitúas en un formulario un "TDecBrowser" y un "TActionList". Acto seguido asignas a la propiedad "Acciones" del "TDecBrowser" el "TActionList" y aun después quitas del formulario el "TActionList"... "violaciones de acceso" variadas e incluso la necesidad (si no le has cogido el truco, y aún así...) de reiniciar Delphi.

Creo que estás perdiendo el punto que señala Juan Antonio.

Estas violaciones de acceso se corrigen, como tú mismo ya lo descubriste, con el método Notification, que está precisamente para eso. Es justo el mecanismo que usa, por ejemplo, un DataSource y su propiedad DataSet.

Pero el caso es que tu código crea una instancia de TActionList:

Código Delphi [-]
FAcciones := TActionList.Create(Forms.Application);

y esto es lo que resulta innecesario si sólo te interesa la referencia al control y no que tu componente la mantenga por sí misma.

// Saludos

[dec]

Hola,

Empezado por roman

Creo que estás perdiendo el punto que señala Juan Antonio.

Estas violaciones de acceso se corrigen, como tú mismo ya lo descubriste, con el método Notification, que está precisamente para eso. Es justo el mecanismo que usa, por ejemplo, un DataSource y su propiedad DataSet.

No, no; si sé perfectamente por dónde va Juan Antonio. Entiendo perfectamente que solamente necesito una referencia y no manejar por mi cuenta un "TActionList"... ¡pero es que me está dando los errores que digo y no consigo hacerlo de otro modo que como he dicho!

Ahora pienso en la cuestión de hacer uso del método "Notification", de otro modo que como lo hago ahora, claro está, supongo, no sé si bien:

Código Delphi [-]
 
 // Notificaciones al componente.
 //
 procedure TDecBrowser.Notification(Component: TComponent;
   Operation: TOperation);
 begin
   inherited;
   if (csDesigning in ComponentState) then
   begin
     if (Operation = opRemove) then
     begin
       if (Component = FAcciones) then
       begin
         FAcciones.RemoveFreeNotification(Self);
         FAcciones := TCustomActionList.Create(Forms.Application);
       end;
     end;
   end;
 end;

El problema ahora mismo está en que si dejo sin crear la variable "FAcciones" al crear el componente ni siquiera puedo poner en un formulario un "TDecBrowser": violaciones de acceso a go-go. Recuerdo que antes busqué por la paleta de componentes alguno que tuviera una propiedad del tipo "TActionList" y que no di con ninguno...

¿Estáis probando esto? Quiero decir, ¿probáis puede hacerse como decís? Porque si es así os agradecería el propio código, más que nada, porque entonces estoy haciendo algo y aun algos mal o no me entero de nada en absoluto,... ambas cosas son posibles.

[dec]

Hola,

Quizá me gustaría añadir por aquello de "si algo funciona, no lo toques" (es broma) que el componente ya no da el problema anteriormente descrito: funciona bien, tanto en tiempo de diseño como en tiempo de ejecución. No digo esto, obviamente, sino para dejar constancia del hecho, por si resultara de alguna utilidad.

[roman]

Vamos a ver.

En tu código tienes:

FAcciones.RemoveFreeNotification(Self);

¿En qué momento agregas tal notificación?

Por otro lado, te das cuenta que cuando Notification se llama con opRemove es porque la componente se está destruyendo. Llamar entonces un método de una componente que se está destruyendo no creo que sea muy seguro.

Yo te recomiendo que te revises en la VCL el código para la propiedad PopupMenu de TControl que te dejará perfectamente claro el uso de FreeNotification y Notification.

EDITO:

No se está destruyendo la componente. Ya se destruyó:

Empezado por ayuda de Delphi

opRemove - The specified object has been destroyed, and its memory is about to be freed.

// Saludos

[dec]

Hola,

Empezado por roman

FAcciones.RemoveFreeNotification(Self);

¿En qué momento agregas tal notificación?

No sé... ¿no la agrega el IDE de Delphi a la que añade el "TActionList" a la propiedad "Acciones" del "TDecBrowser"?

Empezado por roman

Por otro lado, te das cuenta que cuando Notification se llama con opRemove es porque la componente se está destruyendo. Llamar entonces un método de una componente que se está destruyendo no creo que sea muy seguro.

No he inventado nada. Lo he visto en algún componente. Lo digo porque yo no estoy muy puesto que digamos en estos temas y me he fijado en algunos componentes para tratar de solucionar la cuestión planteada aquí. De todos modos debes estar e lo cierto: quitando esa instrucción el componente se comporta como se espera: no falla.

Empezado por roman

Yo te recomiendo que te revises en la VCL el código para la propiedad PopupMenu de TControl que te dejará perfectamente claro el uso de FreeNotification y Notification.

Pues así lo haré. No porque no lo halla hecho ya, pero, porque muy probablemente no lo hice del todo ni bien. En ello estamos.

[[maeyanes]]

Creo que más bien le falta indicarle al TActionList que le notifique al componente TDecBrowser cuando se está destruyendo, esto se haría de la siguiente forma:

Código Delphi [-]
procedure TDecBrowser.SetActionList(Value: TActionList);
begin
  if FActionList <> Value then
  begin
    FActionList := Value;
    if Assigned(Value) then
      Value.FreeNotification(Self)
  end
end;

Ya con eso desde el Notification puedes eliminar la referencia al TActionList cuando este se destruya:

Código Delphi [-]
procedure TDecBrowser.Notification(AComponent: TComponent;
  Operation: TOperation);
begin
  if (Operation = opRemove) and (AComponent = FActionList) then
    FActionList := nil
end;

Saludos...

[roman]

Empezado por maeyanes

Creo que más bien le falta indicarle al TActionList que le notifique al componente TDecBrowser cuando se está destruyendo

¡Exacto! A eso me refería con "agregar la notificación". Y ésta es justo la manera en que se hace con el PopupMenu y otras propiedades similares.

// Saludos

[[Crandel]]

Empezado por andres1569

(según el código que ha puesto Crandel).

Código Delphi [-]
for i:=0 to ComponentCount - 1 do
  if Components[i] is TWebBrowser then
     TWebBrowser(Components[i]).BeforeActivate := MiMetodo;

Al llegar al componente de tipo TDecWebBrowser, ¿se modificaría el evento redefinido o el correspondiente al ancestro? Me inclino por esto segundo, no sé si alguien ha hecho sus pruebas al respecto.

yo también me inclino por porque se va a estar modificando el evento del ancestro, porque se llama directamente al BeforeActivate del TWebBrowser.

Cuidado DEC !!!

Punto a favor de hacerlo con la sugerencia de Roman.

[roman]

Empezado por Crandel

yo también me inclino por porque se va a estar modificando el evento del ancestro, porque se llama directamente al BeforeActivate del TWebBrowser.

No estaría tan seguro. Pero aún así, habiendo un método protegido que controla al evento, prefiero redefinir aquél en lugar de lidiar con una propiedad "artificial". Cuestión de enfoques.

// Saludos

[roman]

Empezado por dec

Lo he visto en algún componente.

¿De la VCL?

// Saludos

[[maeyanes]]

Empezado por roman

No estaría tan seguro. Pero aún así, habiendo un método protegido que controla al evento, prefiero redefinir aquél en lugar de lidiar con una propiedad "artificial". Cuestión de enfoques.

// Saludos

Yo también prefiero usar el enfoque de redefinir los métodos controladores de los eventos, claro, cuando estos existen.


Saludos...

[dec]

Hola,

Yo quisiera verlos en mi caso. He probado lo que me decís en vuestros últimos mensajes. He probado de varias formas. Comprendo que la solución que he logrado no parece la más efectiva o elegante, pero, hasta el momento es la única que funciona. Con todolo demás que he probado, y, repito, he probado, estoy probando y probaré, lo único que obtengo son errores de este jaez:

---------------------------
Error
---------------------------
Access violation at address 0083D670 in module 'vcl70.bpl'. Read of address 00000030.
---------------------------
OK
---------------------------

Lamento ser tan tonto... ¿podría alguien probar en su Delphi (no hay prisa ninguna por mi parte) a retocar el componente de tal modo que funcione correctamente, sobre todo en cuanto al problema que inició este Hilo?

roman, confirmo que estaba demás la instrucción:

Código Delphi [-]
 FAcciones.RemoveFreeNotification(Self);

Quisiera decir que esta frase no me ha caído muy bien:

Empezado por roman

Y ésta es justo la manera en que se hace con el PopupMenu y otras propiedades similares.

Opino que propiedades similares, lo que se dice propiedades similares... no sé yo si lo serán un "TPopupMenu" y un "TActionList". En fin, tampoco diré otra cosa.

Empezado por yo mismo

Lo he visto en algún componente.

Empezado por roman

¿De la VCL?

Pues diría que sí, precisamente. No sé porqué intuía que me preguntarías algo así. Y esta tarde me la he pegado en parte con el tema, y, efectivamente, creo haberlo visto en un componente de la VCL, pero, eso sí, no recuerdo ahora mismo... con lo cual esto que digo queda invalidado en buena medida.

[roman]

Empezado por dec

Quisiera decir que esta frase no me ha caído muy bien

Opino que propiedades similares, lo que se dice propiedades similares... no sé yo si lo serán un "TPopupMenu" y un "TActionList".

Por similares me refiero a que en ambos casos- al menos hasta donde alcanzo a entender de lo que quieres hacer -se trata de propiedades que referencian otras componentes pero que en sí mismas no son mantenidas (creadas, destruídas, etc.) por el control.

// Saludos

[dec]

Hola,

Empezado por roman

Era una forma de decir. No sé porqué sabía que esa frase iba a causarte esa expresión. Si lo sé no la digo.

Empezado por roman

Por similares me refiero a que en ambos casos- al menos hasta donde alcanzo a entender de lo que quieres hacer -se trata de propiedades que referencian otras componentes pero que en sí mismas no son mantenidas (creadas, destruídas, etc.) por el control.

Comprendo. Pero, sigo diciendo que no he sido capaz de hacerlo de otro modo que como lo he hecho. Y que cuando intento otra cosa (lo que parece razonable) falla, al menos hasta ahora.

Por otro lado me estoy pegando con el método "InvokeEvent". Me gustaría utilizarlo, un poco irracionalmente, puesto que el componente, lo diré una vez más, funciona aparentemente bien.

Encuentro este problema:

Código Delphi [-]
   procedure TDecBrowser.InvokeEvent(DispID: TDispID;
     var Params: TDispParams);
   begin
     inherited;
     if DispId = 250 then // 250 - OnBeforeNavigate2
     begin
       // En correspondencia con los parámetros del evento
       // en cuestión, yo precisaría manejar dos parámetros:
       // Params[1] (URL) y Params[6] (Cancel) pero con el
       // el evento puedo hacerlo, esto es, sé hacerlo, lo
       // que no en este método, pues, ¿cómo conseguir algo así?
       // if Params[1] = 'http://unaUrl' then
            {...}
       // El dato contenido en Params[1] ha de ser de tipo
       // "OleVariant".
     end;
   end;

Ahora mismo estoy actuando así en el evento que me interesa y es necesario:

Código Delphi [-]
   procedure TDecBrowser.ComprobarEnlaces(Sender: TObject;
     const pDisp: IDispatch; var URL, Flags, TargetFrameName,
     PostData, Headers: OleVariant; var Cancel: WordBool);
   var
     i: integer;
     enlace: string;
   begin
     Cancel := false;
     for i := 0 to FAcciones.ActionCount-1 do
     begin
       enlace := Format(rsPosibleEnlace,
         [FAcciones.Actions[i].Name]);
       if (URL = AnsiLowerCase(enlace)) then
       begin
         Cancel := true;
         FAcciones.Actions[i].Execute;
       end;
     end;
     if Assigned(FOnBeforeNavigate2) then
     begin
       FOnBeforeNavigate2(Sender, pDisp, URL, Flags,
         TargetFrameName, PostData, Headers, Cancel);
     end;
   end;

[[maeyanes]]

¿Cuál es la última versión de tu componente?, para que le eche un vistazo...

[roman]

Empezado por dec

puesto que el componente, lo diré una vez más, funciona aparentemente bien.

Bueno, entonces no nos hagas caso. Si te funciona bien y estás a gusto con el resultado pues ¿a qué darle más vueltas?

// Saludos