FTP | CCD | Buscar | Trucos | Trabajo | Foros |
|
Registrarse | FAQ | Miembros | Calendario | Guía de estilo | Temas de Hoy |
|
Herramientas | Buscar en Tema | Desplegado |
#41
|
||||
|
||||
Hola,
Cita:
Cita:
|
#42
|
|||
|
|||
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... |
#43
|
||||
|
||||
Primero, lamento no haber llegado antes... francamente sigo corto de tiempo.
Cita:
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: Hasta luego.
__________________
Juan Antonio Castillo Hernández (jachguate) Guía de Estilo | Etiqueta CODE | Búsca antes de preguntar | blog de jachguate |
#44
|
||||
|
||||
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. |
#45
|
||||
|
||||
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 |
#46
|
||||
|
||||
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 |
#47
|
|||
|
|||
Cita:
Saludos... |
#48
|
||||
|
||||
Hola,
Cita:
Cita:
Cita:
Lo adjunto aquí según yo lo tengo guardado, por si quiere alguien echarle un vistazo. Gracias a todos otra vez. |
#49
|
|||
|
|||
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).
__________________
Guía de Estilo |
#50
|
||||
|
||||
Hola,
Cita:
|
#51
|
||||
|
||||
Cita:
Cita:
// Saludos |
#52
|
|||
|
|||
Cita:
__________________
Guía de Estilo |
#53
|
|||
|
|||
Cita:
__________________
Guía de Estilo |
#54
|
||||
|
||||
Hola,
Cita:
|
#55
|
||||
|
||||
Cita:
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.
__________________
Juan Antonio Castillo Hernández (jachguate) Guía de Estilo | Etiqueta CODE | Búsca antes de preguntar | blog de jachguate |
#56
|
||||
|
||||
¡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. Última edición por Al González fecha: 31-01-2010 a las 05:23:23. Razón: Era InvokeEvent, no Invoke. :) |
#57
|
||||
|
||||
...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. |
#58
|
|||||
|
|||||
Hola,
Cita:
Cita:
Cita:
Cita:
Cita:
Un abrazo y medio. |
#59
|
||||
|
||||
¡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. |
|
|
|