Pregunta

Utilizamos C ++ Builder para una aplicación cuyos formularios se mantienen externos al EXE en una base de datos. El código de la aplicación es C ++

Esto nos permite modificar los formularios y formularios / acciones sin una nueva compilación. Aquí hay un fragmento de código que hace el trabajo de cargar un formulario.

 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();

Tengo curiosidad por saber si hay funciones incorporadas a las que pueda llamar para registrar todas las clases a las que se hace referencia. Supongo que es posible escanear el flujo de memoria o el archivo de todos los objetos y llamar a RegisterClass para cada uno, pero esperaba que alguien supiera de la función que ya hizo esto.

Como tal, no todas las formas usan todas estas clases tampoco, por lo que sería bueno registrar solo las que realmente se heredan.

¿Fue útil?

Solución

El enfoque que tiene aquí es exactamente correcto, en mi opinión. Tomé el mismo enfoque hace años usando Delphi2, aunque tuve que implementar mi propia fábrica de clases y las funciones ObjectToText / TextToObject ya que ReadComponent () nunca apareció en el VCL.

En su segundo punto de registrar solo las clases requeridas, ¿seguramente solo necesitan registrarse una vez? Y la sobrecarga de determinar si una clase necesita ser registrada, superará el costo de registrar todo. Nuevamente, lo dejaría como está.

Otros consejos

No conozco ninguna función existente; para mí, parece algo bastante raro. El enfoque de almacenar formularios DFM en una base de datos (¿se almacenan por separado en los archivos CPP y H para la unidad?) También es extraño. Sé que dices & Quot; Esto nos permite modificar los formularios y formularios / acciones sin volver a compilar & Quot; pero personalmente los almacenaría en un archivo DLL y los volvería a compilar; al menos, dependiendo de su sistema de compilación, será versionado y tendrá su unidad almacenada como " unit " . Admito que no conozco los requisitos de tu sistema y probablemente tengas una buena razón para hacerlo a tu manera.

Sin embargo, dado su enfoque, creo que escanear el flujo, buscar cláusulas de objeto y registrar esos componentes antes de llamar a ReadComponent es probablemente el mejor enfoque.

Almacenar el DFM por separado (para cambiar solo los eventos y los controladores de acciones) aún deja los archivos CPP y H compilados en su aplicación principal. A partir de eso, ¿ya no tendría los componentes registrados e integrados, por lo que esto es completamente innecesario?

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top