![]() |
![]() |
| Paypal | FTP | CCD | Buscar | Trucos | Trabajo | Foros |
|
|||||||
| Registrarse | FAQ | Miembros | Calendario | Guía de estilo | Buscar | Temas de Hoy | Marcar Foros Como Leídos |
|
|
Herramientas | Buscar en Tema | Desplegado |
|
#11
|
||||
|
||||
|
Cita:
El ejemplo que pones es incompleto y no vemos cómo estás construyendo el objeto que le pasas a GetInt64Prop. Fíjate en una cosa: TPersistent no es una clase virtual, esto es, su constructor Create no es virtual. Esto es importante, porque si construyes objetos a partir de referencias de clase- como lo es cuando usas el valor que devuelve GetClass -tal referencia debe apuntar a una clase virtual, de lo contrario, la construcción se resuelve desde el momento de la compilación usándose el constructor base de TPersistent y no el de la clase heredada. Puedes resolver eso, metiendo un constructor virtual en tu clase A que incluso puedes dejar abstracto e implementarlo hasta la clase B, o bien dejarlo vacío (un procedimiento que no haga nada) y la clase B puede o no redefinirlo. Pero cuando construyas la clase debes usar una referencia a tu clase A y no a TPersistentClass. Algo como:
Y usas TBaseClass para hacer un moldeo con el valor que te devuelve GetClass.
Como Aclass apunta ahora a una clase virtual, el compilador sabe ya que no puede resolver el constructor y debe dejarlo hasta el momento de la ejecución. Otra cosa, es que no veo cómo estás definiendo la clase en cuestión: recuerda que las propiedades a las que quieres acceder deben estar en una sección published. Además, en mi opinión, no hay necesidad de usar TPersistent. TPersistent y TComponent son las clases bases para el manejo de la persistencia en los archivos dfm. Si tú no requieres tal funcionalidad, no veo porqué usarlo. Cualquier clase puede generar RTTI siempre y cuando se compile con la directiva {$M+}. Como TPersistent está compilado de esa forma, ella, y todas las classes descendientes, generan RTTI. Pero puedes lograr lo mismo si lo haces tú mismo:
Claro que en esta situación no te va a servir GetClass. Pero GetClass y RegisterClass lo único que hacen es mantener una asociación: nombre de clase => clase que tú mismo puedes implementar fácilmente. Y finalmente, de hecho no entiendo para qué quieres usar RTTI. Hasta donde recuerdo, tu puedes tener una unidad común, digamos Core que defina tu clase base, si quieres con sólo métodos abstractos para que haga lo mínimo indispensable. Entonces, incluyes esa unidad Core, tanto en la aplicación principal como en el paquete dinámico. Dado que en Core estás definiendo la interfaz de tu clase, puedes acceder a los métodos y propiedades sin recurrir a las argucias de RTTI. Claro está, siempre y cuando te bases en una clase virtual, según te comenté arriba. Eso sí, tienes que implementar tu propio registro nombre de clase => clase pero eso es relativamente sencillo. Puedes tener en Core un arreglo
y funciones globales:
// Saludos Última edición por roman fecha: 06-03-2007 a las 05:31:55. |
| Herramientas | Buscar en Tema |
| Desplegado | |
|
|
Temas Similares
|
||||
| Tema | Autor | Foro | Respuestas | Último mensaje |
| Usar una clase que esta dentro de una libreria | lookmydoom | OOP | 3 | 18-04-2006 15:25:34 |
| Obtener el directorio donde está el ejecutable | daly | Varios | 3 | 13-10-2005 19:29:18 |
| Propiedad que me indica si un DBMemo está vacio | gluglu | Varios | 4 | 10-02-2005 16:48:17 |
| Una clase como propiedad de un componente? | setry2 | OOP | 3 | 30-12-2003 21:30:58 |
| Obtener la clase de objetos | Feñiz | OOP | 7 | 08-05-2003 20:21:55 |
|