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

[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

[[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

[[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

[dec]

Hola,

Empezado por maeyanes

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

Acabo ahora de actualizarlo aquí mismo.

Empezado por roman

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?

Ya he dicho más arriba roman que no digo eso por decir, ni mucho menos por dar a entender algo como lo que dices: lo digo por si sirve de algo, porque es un hecho comprobado. ¡Pero si no he hecho sino haceros caso! He hecho varios cambios, de hecho he solucionado el problema (tal y como está ahora solucionado, vaya) a partir del inicio de este Hilo, de otro modo no hubiera sido posible: ya ves si os hago caso o no.

[[Al González]]

¡Hola a todos!

Vaya hilo. Se mezcló lo del TActionList con lo de agregar comportamiento relacionado con un evento a una clase descendiente. Me resultó un poco difícil leerlo, porque las muestras de código tienen líneas demasiado largas para una resolución de 800X600.

Dec: Te aconsejo que optes por la recomendación de Román respecto al método virtual InvokeEvent.

Verás, la óptica es esta: Si existe un método virtual que llama directa o indirectamente a un manejador de evento, lo mejor es tratar de redefinir ese método y agregar ahí la nueva funcionalidad relacionada con el evento.

Si por alguna razón (técnica o lógica) prefieres redefinir la propiedad evento, ten en cuenta lo siguiente:
1. No necesitas usar Load.
2. Puedes redeclarar la propiedad evento en la nueva clase y con el mismo nombre para ocultar la propiedad padre ante el inspector de objetos, guardando la nueva propiedad en un nuevo campo.
3. Desde el método que asignes internamente a la propiedad oculta puedes llamar al nuevo evento.
4. Si la propiedad original no está definida con métodos de acceso virtuales, tu componente tendrá el riesgo que señala Andrés, al hacer referencias polimórficas (se operará sobre la propiedad padre, no la nueva).

Espero esto sea de utilidad.

Un abrazo orientado a objetos.

Al González.