Cómo codificar en el evento (incluso asignado) de un componente - Página 3

dec · #41 03-11-2005

Hola,

Cita:

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.

Cita:

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.

[maeyanes] · #42 03-11-2005

Bueno, aquí te subo una versión (que por falta de tiempo no compilé) modificada para que trabaje con un ActionList externo. Fíjate que en donde haces uso de FAcciones, primero verifico que esté asignado antes de usarlo.

También comenté las lineas donde creas y destruyes FAcciones, ya que tu componente no debería hacerlo.

Cualquier duda o comentario, será hasta mañana que te conteste...

Saludos...

jachguate · #43 03-11-2005

Primero, lamento no haber llegado antes... francamente sigo corto de tiempo.

Cita:

Empezado por maeyanes

donde haces uso de FAcciones, primero verifico que esté asignado antes de usarlo.

También comenté las lineas donde creas y destruyes FAcciones, ya que tu componente no debería hacerlo.

¡¡¡Ecole!!! ¡¡Eureka!!

Este es el punto. No basta con que hagas que FAcciones sea nil cuando se libera la referencia... falta verificar, antes de usar este puntero, que apunte a algún lado, y no a nil. Es decir, cada vez que se use:

Código Delphi [-]  if FAcciones <> nil then
    Procesar(FAcciones)
  else
    Raise Exception.Create('Error: debe asociar un componente TActionList'
      + ' antes de usar el TDecWebBrowser');

Hasta luego.

dec · #44 04-11-2005

Hola,

Aquí es donde cuadra aquello de zapatero, a tus zapatos; de no por mucho madrugar amanece más temprano; de sabe el zorro más por viejo que por zorro; de... ¡Al fin lo habéis conseguido!

Ahora todo parece funcionar correctamente, sin necesidad de ser prolijo, como lo estaba siendo yo antes. El código enviado por maeyanes (muchas gracias) me lo demostró, aunque, como alguien apuntó arriba, estaba todo dicho...

El problema estaba en no verificar que la variable "FAcciones" no fuera "nil" desde un principio,... y trataré de explicarme. Yo he pasado por hacer todo cuanto se me decía, pero, no comprendía (menudo ripio) que fuera preciso verificar que la variable "FAcciones" no fuera "nil" allá donde fuera necesario su usu.

¿Por qué digo esto? Pues porque me paraba en cierto error que se producía nada más alojar el componente en el formulario: sin que pudiera hacerse nada más, ni siquiera asignar un componente "TActionList". ¿Cómo iba a pensar que fuera necesario verificar algo que se sabe a ciencia cierta no existe todavía?

Pues así parece ser, en este caso: no he hecho muchas pruebas, pero, desde luego, ahora, gracias a vosotros (pues que si no el componente se hubiera quedado en una barbaridad por los siglos de los siglos, amén) el componente funciona y eso es, básicamente, lo que se ha cambiado: ahora se verifica que exista una referencia en "FAcciones" antes de hacer uso de dicha variable.

En fin. Casi 50 mensajes para este Hilo no están nada mal... probablemente debí de haber cogido el Hilo del asunto muy antes, pero, no fue así, probablemente porque al encontrar YO (mi tesoro) una solución (MALÍSIMA) me cerré demasiado en ella, que todo hay que decirlo, aunque esta vez se sepa.

Lo dicho, gracias a todos de nuevo. De verdad.

roman · #45 04-11-2005

Una última cosa. Esto seguro es un error de dedo. En el código que tienes en tu página (lo acabo de bajar), en el método ComprobarEnlaces, donde dice

if not Assigned(FAcciones) then

creo que debe decir

if Assigned(FAcciones) then

// Saludos

roman · #46 04-11-2005

Ya sé que era la última cosa pero es justo decir lo siguiente.

Durante todo el hilo mi mente se enfocó en algunas partes puntuales pero la verdad no tenía claro cuál era el funcionamiento de la componente de David.

Finalmente he logrado ejecutar el ejemplo y puedo decir que me ha parecido una idea muy interesante y original.

// Saludos

[maeyanes] · #47 04-11-2005

Cita:

Empezado por roman

Una última cosa. Esto seguro es un error de dedo. En el código que tienes en tu página (lo acabo de bajar), en el método ComprobarEnlaces, donde dice

if not Assigned(FAcciones) then

creo que debe decir

if Assigned(FAcciones) then

// Saludos

Lo más seguro, y también es seguro que viene de lo que yo hice, ya que fue hecho a unos minutos de que me retirara del trabajo, y como mencioné, no lo pude compilar y probar para verificarlo...

Saludos...

dec · #48 04-11-2005

Hola,

Cita:

Empezado por roman

Una última cosa. Esto seguro es un error de dedo. En el código que tienes en tu página (lo acabo de bajar), en el método ComprobarEnlaces, donde dice

Código Delphi [-]  if not Assigned(FAcciones) then

creo que debe decir

Código Delphi [-]  if Assigned(FAcciones) then

Así es la verdad. Ya lo he corregido y he vuelto a actualizar el componente. Se me pasó.

Cita:

Empezado por maeyanes

Lo más seguro, y también es seguro que viene de lo que yo hice, ya que fue hecho a unos minutos de que me retirara del trabajo, y como mencioné, no lo pude compilar y probar para verificarlo...

Sí; ya lo creo que así. Copiar y pegar es lo que tiene, sobre todo a ciertas horas.

Cita:

Empezado por roman

Ya sé que era la última cosa pero es justo decir lo siguiente.

Durante todo el hilo mi mente se enfocó en algunas partes puntuales pero la verdad no tenía claro cuál era el funcionamiento de la componente de David.

Finalmente he logrado ejecutar el ejemplo y puedo decir que me ha parecido una idea muy interesante y original.

Bueno, roman, pues me alegro de que te parezca curioso el asunto: puedes hacer uso de la idea y del componente y/o de su código para lo que te apetezca. Yo mismo recogí la idea de "HTML Application Demo", un ejemplo curioso que tenía guardado hace tiempo y que hube descargar de DelphiBox, si el "readme.txt" no me engaña...

Lo adjunto aquí según yo lo tengo guardado, por si quiere alguien echarle un vistazo. Gracias a todos otra vez.

andres1569 · #49 04-11-2005

Hola,

una cosita, hay que poner la llamada al método Notification del ancestro, que se encarga de liberar la referencia a nuestro componente de la lista de componentes ligados (FFreeNotifies).

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

dec · #50 04-11-2005

Hola,

Cita:

Empezado por Andrés

una cosita, hay que poner la llamada al método Notification del ancestro, que se encarga de liberar la referencia a nuestro componente de la lista de componentes ligados (FFreeNotifies).

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

Bueno. Lo cierto es que suelo hacerlo así como dices Andrés, empero, ¿no es igualmente válido utilizar, digamos, la abreviatura, tal como se ve abajo? Yo diría que así es, aunque no fundamentado en letra impresa, sino en la poca experiencia que tengo en estas lides.

Código Delphi [-] // Notificaciones al componente.
 //
 procedure TDecBrowser.Notification(Component: TComponent;
   Operation: TOperation);
 begin
   inherited;
   if (Operation = opRemove)
     and (Component = FAcciones) then
       FAcciones := nil
 end;

roman · #51 04-11-2005

Cita:

Empezado por dec

Yo diría que así es, aunque no fundamentado en letra impresa

Y bien fundamentado que está:

Cita:

Empezado por ayuda de Delphi SIETE

When inherited has no identifier after it, it refers to the inherited method with the same name as the enclosing method or, if the enclosing method is a message handler, to the inherited message handler for the same message. In this case, inherited takes no explicit parameters, but passes to the inherited method the same parameters with which the enclosing method was called.

Enfatizo el siete ya que en versiones antiguas creo recordar que sí había que pasar todos los parámetros. No sé qué versión usa Andrés

// Saludos

andres1569 · #52 04-11-2005

Cita:

Empezado por dec

Bueno. Lo cierto es que suelo hacerlo así como dices Andrés, empero, ¿no es igualmente válido utilizar, digamos, la abreviatura, tal como se ve abajo?

Sí. Y además está documentado.

andres1569 · #53 04-11-2005

Cita:

Empezado por roman

Enfatizo el siete ya que en versiones antiguas creo recordar que sí había que pasar todos los parámetros. No sé qué versión usa Andrés

Enfatizo el CUATRO, EL CINCO Y EL SEIS, tampoco sé si había dicha forma de abreviar en versiones anteriores.

dec · #54 04-11-2005

Hola,

Cita:

Empezado por roman

Y bien fundamentado que está:

Cita:

Empezado por ayuda de Delphi SIETE

When inherited has no identifier after it, it refers to the inherited method with the same name as the enclosing method or, if the enclosing method is a message handler, to the inherited message handler for the same message. In this case, inherited takes no explicit parameters, but passes to the inherited method the same parameters with which the enclosing method was called.

Así es la verdad. Diré en mi favor que estoy un poco liado ahora mismo con TXEditor, ayuda a la traducción del programa XEditor, y que por eso no me cercioré en la ayuda sobre el asunto.

jachguate · #55 05-11-2005

Cita:

Empezado por roman

Enfatizo el siete ya que en versiones antiguas creo recordar que sí había que pasar todos los parámetros. No sé qué versión usa Andrés

Puedo dar fe que al menos desde delphi 3 no es necesario, y creo recordar que es una característica incluida en el propio delphi 1.

De mi (mala) memoria, podría afirmar que en Turbo Pascal 7, si que había que pasar los parámetros. En turbo pascal 6 no existía inherited, y por consiguiente había que llamar al método de la clase padre por nombre y apellidos, por supuesto, pasando los parámetros).

Hasta luego.

[Al González] · #56 12-11-2005

¡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.

[Al González] · #57 12-11-2005

...Con respecto al uso abreviado de Inherited, hace algún tiempo que lo desacostumbré porque imposibilita usar la opción Find Declaration para ir rápidamente al código del método heredado.

Un abrazo complementario.

Al González.

dec · #58 13-11-2005

Hola,

Cita:

Empezado por Al González

...Con respecto al uso abreviado de Inherited, hace algún tiempo que lo desacostumbré porque imposibilita usar la opción Find Declaration para ir rápidamente al código del método heredado.

Una cosa más que sé. Gracias Al.

Cita:

Empezado por Al González

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

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.

No lo haré así, por el momento, aunque acabo de intentarlo de nuevo. Por el momento quédese como está el asunto, aunque, no dudo que sea más efectivo hacer lo que dices, no he podido conseguirlo. ¿Porqué no pregunto por aquí? ¡Hoy no, que me da pereza!

Cita:

Empezado por Al González

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.

No se hace uso de "Load", quizá se planteó, pero, ahora mismo no se hace uso de ese método.

Cita:

Empezado por Al González

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.

Se agradece la información. De todos modos ahora la propiedad está "heredada", de tal forma que el componente puede hacer uso del evento y el usuario del componente también, del mismo evento: el evento llegará antes al usuario que al componente.

Cita:

Empezado por Al González

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).

Aquí ya me pierdo un poco Al. Llego hasta decir que la propiedad original, efectivamente, no está definida con métodos de acceso virtuales. El riesgo que corre el componente (o el usuario del mismo) no logro captarlo. Acaso haga alguna que otra prueba Al. En cualquier caso gracias por tus comentarios.

Un abrazo y medio.

[Al González] · #59 31-01-2010

¡Hola de nuevo!

Después de cuatro años.

Vine a parar a este hilo buscando en Google ejemplos de clases derivadas de TWebBrowser que redefinieran el método InvokeEvent. He estado inclinado a redefinir ese método para añadir comportamiento a los eventos OnNavigateComplete2 y OnDocumentComplete.

Después de haber echado un nuevo vistazo al tema, reafirmo mi intención de redefinir a InvokeEvent. Fue la propuesta que puntualmente hizo Román en aquel entonces para el planteamiento de Dec.

La razón para interceptar esos eventos es dotar al componente de la capacidad de saber cuándo realmente ha terminado de navegar, pues las propiedades Busy y ReadyState me cuentan "mentiras" con ciertas páginas. Haciendo algunas pruebas, he notado que ReadyState puede alcanzar un valor de ReadyState_Complete antes de que varios elementos de la página estén presentes, mientras que el evento OnDocumentComplete sí que tiene la última palabra (se dispara por última vez cuando tales elementos ya están disponibles).

Saludos.

Al González.

P.D.

David, ignoro si aún tienes aquella última duda que planteabas.

Andrés, amigo, me resultó grato leerte nuevamente.