No puede heredar un tipo
 

Hola, he declarado en una unidad la siguiente sintaxis:

Código Delphi [-]
unit General;
interface
uses IdComponent; // INDY 10
type TIdStatus = IdComponent.TIdStatus; // Viene de la unidad IdComponent de INDY 10
 
type TGeneral = Class(TObject)
...

La unidad IdComponent es una unidad de Indy 10 y dentro de esta unidad esta declarada la enumeracion TIDStatus:

Código Delphi [-]
TIdStatus = (
  hsResolving,
  hsConnecting,
  hsConnected,
  hsDisconnecting,
  hsDisconnected,
  hsStatusText,
  ftpTransfer,
  ftpReady,
  ftpAborted
);

Hasta acá todo bien, despues dentro del formulario principal creo una instancia de la clase TGeneral, defino una variable de tipo TIdStatus y al crear el form quiero asignarle el valor hsDisconnected a esta variable, acá es donde está el problema, me dá un error E2003 diciendo que hsDisconnected es un identificador sin declarar.
En realidad es cierto, ya que hsDisconnected no está definido ni en la unidad del form ni en la unidad General, pero he definido un tipo TIDStatus el cual desciende de IdComponent.TidStatus, por lo que los valors de TIdStatus deberian ser accesibles desde el form.
Obviamente desde la unidad General puedo acceder a los valores del enumerador TIdStatus, pero no mas allá de la unidad General.

Alguna idea ?

Declaración innecesaria
 

¡Hola a todos!

Fafastrungen:

Una declaración como

Código Delphi [-]
type TIdStatus = IdComponent.TIdStatus;

no crea herencia o descendencia (por lo menos en sentido orientado a objetos). Es sólo una declaración de tipo, con la cual le indicas al compilador que trate a un nuevo tipo de dato como equivalente de otro declarado previamente.

Cuando en la unidad de la forma, el compilador te señala que el identificador hsDisconnected no está declarado, es porque no tienes en alguna de sus cláusulas Uses el nombre de la unidad que declara esa constante (IdComponent).

En todo caso, por lo que puede apreciarse, es innecesaria la redeclaración del tipo de dato TIdStatus. Basta que agregues la unidad IdComponent al Uses de la implementación de la forma:

Código Delphi [-]
implementation

{$R *.dfm}

Uses
  IdComponent;

Un abrazo declarado.

Al González. :)

Gracias Al por la respuesta y la verdad que no sabia que no se podía heredar un enumerador.
Lo he solucionado como comentas, agregando la unidad IDComponent a la unidad del form, pero lo que yo quería era independizar completamente, osea, quiero que todo esté contenido en la unidad General y no tener que agregar codigo al resto de unidades que usan General.
Lo que quería lograr era que sea suficiente con solo declarar la unidad General dentro del codigo que vaya a implementar, de esta forma no tengo que declarar nada mas, ya que si tengo, supongamos groseramente, 100 forms que usan la unidad General, tendría que declarar dentro de cada unidad de los 100 forms la unidad General y la unidad IdComponent, en cambio si se pudiera lo que quiero, con solo declarar la unidad General sería suficiente, ya que IdComponent estaría declarada en General.

Gracias de nuevo.

¡Hola a todos!

Es bueno saber que está solucionado.

Pero, retomando la interesante reflexión que haces, cabe añadir que escribir el nombre de una unidad en una cláusula Uses no se compara en nada con escribir el resto del código que normalmente va dentro de una unidad.

No obstante, cuando es necesario repetir en varios lugares una sección de código bastante significativa para el autor, y, por su naturaleza, dicho código no puede ser sometido a los dominios de una función (por ejemplo una cláusula Uses con varios nombres de unidades), es posible recurrir al uso de directivas $Include:

Código Delphi [-]
  Uses
    {$Include NombresDeUnidades1.inc}, SysUtils, Variants;

Aunque francamente desaconsejaría esta práctica en tu caso.

Además, en un grupo de cien unidades que hacen referencia a un mismo elemento de otra unidad, es muy probable que exista una buena cantidad de código común relacionado con el uso de dicho elemento, código que podría sintetizarse mediante la creación de nuevas funciones o una buena revisión a la jerarquía de clases. Recuerda que las formas sí pueden derivar (descender / heredar) de otras formas; muchos OnCreate con el mismo código, por ejemplo, pueden convertirse en un sólo OnCreate colocado en una plantilla "base", o cuando menos concentrar en éste lo que es común para todos aquellos.

Espero también esto sea de utilidad.

Un {$Abrazo+}.

Al González. :)

Todo lo que sea informacion es bienvenida, por lo que muchas gracias.