¿Por qué no aparecen los campos de un descendiente de ClientDataSet en el momento de diseño?

Question

Estoy tratando de escribir un componente que hereda de Tclientdataset. En la creación del componente en el tiempo de diseño, quiero instanciar una lista de campos comunes que se usan dentro de mi marco. El siguiente código se ejecutará sin errores y el campo aparecerá en el tiempo de ejecución pero no en el tiempo de diseño. ¿Alguien puede ayudarme? ¡Estoy seguro de que es algo trivial!

{ InheritedClientDataset }

constructor InheritedClientDataset.Create(AOwner: TComponent);
var
  Field : TField;
begin
  inherited;

  Field := TField.Create(self);
  Field.Name := 'ATestField';
  Field.FieldName := 'Test';
  Field.SetFieldType(ftInteger);
  //Field.DataType := ftInteger;
  Field.Size := 0;
  Field.FieldKind := fkData;

  self.Fields.Add(Field);
end;

Answer 1

Intente crear su campo usando su FieldType. Por ejemplo, Tintegerfield.

  MyField := TIntegerField.Create(Self);
  MyField.FieldName := 'MyFieldName';
  MyField.DataSet := Self;
  MyField.Name := Self.Name + '_' + MyField.FieldName;

Eso debería funcionar.

Estará disponible para los controles, pero no para el editor de campos.

Answer 2

Totalmente no probado, pero probablemente deberías agregar a Fielddefs: en su lugar:

with FieldDefs.AddFieldDef do
begin
  DataType := ftInteger;
  Name := 'Field1';
end;

with FieldDefs.AddFieldDef do
begin
  DataType := ftString;
  Size := 25;
  Name := 'Field2';
end;

También es posible que deba agregar una llamada a CreativeAtAset después de que se agregan FieldDefs:

// After above code...
inherited CreateDataSet;

Answer 3

Tengo la sensación de que en casos como este, podría estar en contra de la intención de diseño del componente VCL Designtime. Los campos generalmente están definidos por alguien que coloca un objeto de tabla en un módulo de datos, luego establece las propiedades del conjunto de datos en un SQL u otra tabla en particular y selecciona los campos de esa tabla, en lugar de un componente con un conjunto fijo de campos, que podrían ser Algo problemático para que la arquitectura actual lo admita, aunque tenga una solución, ¿está seguro de que no hay problemas con ese enfoque?

¿Has pensado en un enfoque alternativo? (Escriba un componente con una propiedad pública que permita que esté conectado a un conjunto de datos o una fuente de datos y coloque toda su lógica del marco en ese componente). Deje la clase de conjunto de datos solo.

¿Realmente necesita hacer una relación "es una" en términos OOP, o su código realmente sería más limpio si considere "tiene un enlace a un conjunto de datos"?