Cita:
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 |
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:
Hasta luego. ;) |
Cita:
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í:
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. :rolleyes: Quizás esa sea una de las pegas de enmascarar una propiedad / método, que se está induciendo a un posible error. Saludos |
Hola,
Cita:
Cita:
Cita:
Pero, me parece que comienzo a desvariar... Gracias de nuevo a todos. ;) |
Cita:
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:
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 |
Hola,
Cita:
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: 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. :D |
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. ;) |
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ó: Cita:
|
Hola,
Cita:
Cita:
Cita:
|
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:
Ya con eso desde el Notification puedes eliminar la referencia al TActionList cuando este se destruya:
Saludos... |
Cita:
// Saludos |
Cita:
Cuidado DEC !!! Punto a favor de hacerlo con la sugerencia de Roman. |
Cita:
// Saludos |
Cita:
// Saludos |
Cita:
Saludos... |
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: Cita:
roman, confirmo que estaba demás la instrucción: Quisiera decir que esta frase no me ha caído muy bien: Cita:
Cita:
Cita:
|
Cita:
Cita:
// Saludos |
Hola,
Cita:
Cita:
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: Ahora mismo estoy actuando así en el evento que me interesa y es necesario:
|
¿Cuál es la última versión de tu componente?, para que le eche un vistazo... :)
|
Cita:
// Saludos |
La franja horaria es GMT +2. Ahora son las 13:42:33. |
Powered by vBulletin® Version 3.6.8
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Traducción al castellano por el equipo de moderadores del Club Delphi