Question

Nous utilisons C ++ Builder pour une application dont les formulaires sont conservés à l'extérieur du fichier EXE dans une base de données. Le code de l'application est C ++

Cela nous permet de modifier les formulaires et formulaire / actions sans recompiler. Voici un extrait de code qui permet de charger un formulaire.

 RegisterClass(__classid(TButton));
 RegisterClass(__classid(TEdit));
 RegisterClass(__classid(TRadioGroup));
 RegisterClass(__classid(TGroupBox));
 RegisterClass(__classid(TCheckBox));
 RegisterClass(__classid(TRadioButton));
 RegisterClass(__classid(TTimer));
 RegisterClass(__classid(TListBox));
 RegisterClass(__classid(TComboBox));
 RegisterClass(__classid(TBitBtn));
 RegisterClass(__classid(TSpeedButton));
 RegisterClass(__classid(TMaskEdit));
 RegisterClass(__classid(TProgressBar));

 ms  = new TMemoryStream;
 ms2 = new TMemoryStream;

 // Loading Module into Memory Stream
 ms->Position = 0;
 ms->LoadFromFile(Filename->Text);
 ms->Position = 0;
 pModule = new TForm(this);

 // Reading Module Definition
 if( !Inputisbin->Checked )
 {
        ms2->Position = 0;
        ObjectTextToBinary(ms, ms2);
        ms2->Position = 0;
        ms2->ReadComponent(pModule);
 }
 else
        ms->ReadComponent(pModule);


 Log->Lines->Add("Displaying Module");
 pModule->Show();

Je suis curieux de savoir s’il existe des fonctions intégrées que je peux appeler pour enregistrer toutes les classes référencées. Je suppose qu’il est possible d’analyser moi-même le flux ou le fichier de mémoire pour tous les objets et d’appeler RegisterClass pour chacun d’entre eux, tout en espérant que quelqu'un connaisse la fonction qui l'a déjà fait.

En tant que tel, toutes les formes n'utilisent pas non plus toutes ces classes, il serait donc agréable d'enregistrer uniquement celles qui sont réellement héritées.

Était-ce utile?

La solution

L’approche que vous avez ici est tout à fait juste, à mon avis. J’ai adopté la même approche il ya des années en utilisant Delphi2, bien que j’ai dû implémenter ma propre fabrique de classes et mes fonctions ObjectToText / TextToObject en tant que ReadComponent () n’ayant jamais été intégré à la VCL.

Sur votre deuxième point d’inscription uniquement aux cours obligatoires, ils n’ont sûrement besoin que d’un enregistrement? Et les frais généraux liés au fait de déterminer si une classe doit être enregistrée l'emporteront sur le coût de toute inscription. Encore une fois, je le laisserais tel quel.

Autres conseils

Je ne connais aucune fonction existante - cela me semble une chose assez rare à faire. L’approche consistant à stocker des formulaires DFM dans une base de données (ils sont stockés séparément dans les fichiers CPP et H de l’unité?) Est également étrange. Je sais que vous dites & «Cela nous permet de modifier les formulaires et les formes / actions sans recompiler &»; mais personnellement, je les stockais dans une DLL et les recompilais. Du moins, selon votre système de compilation, il sera versionné et votre unité sera stockée sous la forme d'une & "unité &"; . J'avoue que je ne connais pas vos exigences système et que vous avez probablement une bonne raison de le faire à votre façon.

Toutefois, étant donné votre approche, analyser le flux, rechercher des clauses d'objet et enregistrer ces composants avant d'appeler ReadComponent est probablement la meilleure approche.

Le stockage séparé du DFM (afin de modifier simplement les événements et les gestionnaires d’actions) conserve les fichiers PPC et H compilés dans votre application principale. A partir de là, les composants ne seraient-ils pas déjà enregistrés et intégrés, ce qui est donc totalement inutile?

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top