Pourquoi les champs d'un descendant ClientDataset n'apparais-ils pas au moment de la conception?

Question

J'essaie d'écrire un composant qui hérite de TClientDataset. Sur la création du composant en temps de conception, je souhaite instancier une liste de champs communs utilisés dans mon cadre. Le code ci-dessous s'exécutera sans erreurs et le champ apparaîtra au moment de l'exécution mais pas le temps de conception. Quelqu'un peut-il m'aider? Je suis sûr que c'est quelque chose de 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

Essayez de créer votre champ en utilisant son FieldType. Par exemple, Tintegerfield.

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

Cela devrait fonctionner.

Il sera disponible pour les contrôles mais pas l'éditeur de champs.

Answer 2

Totalement non testé, mais vous devriez probablement ajouter à FieldDefs à la place:

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

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

Vous devrez peut-être également ajouter un appel à CreateDataSet après l'ajout des champs de champ:

// After above code...
inherited CreateDataSet;

Answer 3

J'ai le sentiment que dans des cas comme celui-ci, vous pourriez aller à l'encontre de l'intention de conception du VCL Component Designtime. Les champs sont généralement définis par quelqu'un qui place un objet de table sur un module de données, puis définissez les propriétés de l'ensemble de données sur un SQL ou une autre table particulière et sélectionne les champs de ce tableau, plutôt qu'un composant avec un ensemble fixe de champs, qui pourrait être Quelque chose de problématique pour l'architecture actuelle à prendre en charge, même si vous avez une solution, êtes-vous sûr qu'il n'y a pas de problèmes avec cette approche?

Avez-vous pensé à une approche alternative? (Écrivez un composant avec une propriété publique qui lui permet d'être connecté à un ensemble de données ou à une source de données et à mettre toute votre logique de framework dans ce composant). Laissez la classe d'ensemble de données tranquille.

Avez-vous vraiment besoin de faire une relation "est" en termes OOP, ou votre code serait-il réellement plus propre si vous envisagez "un lien vers un ensemble de données" à la place?