I'm developing an application with a lot of small, custom dialogs.
These dialogs are e.g. giving choices, displaying graphs or offer additional interfaces. Mostly they require very little markup-code and have few child elements.
Currently I'm using embarcadero'c XE2 RAD Studio's C++ Builder, which works with VCL and generates for every form a .dfm file, a .h file and a .cpp file. Now I would like to keep an overview over the files produced and merge e.g. the .dfm files of multiple small dialogs. (maybe even the .cpp and .h, too). However, I also want to use C++-Builder's VCL designer.
Is there a way to merge .dfm files and still have the IDE's designer working as usual?
Or should I just dynamically generate those dialogs during runtime?
Now I would like to keep an overview over the files produced and merge e.g. the .dfm files of multiple small dialogs. (maybe even the .cpp and .h, too). However, I also want to use C++-Builder's VCL designer.
Is there a way to merge .dfm files and still have the IDE's designer working as usual?
It is possible (but not recommended) to move design-time generated event handler implementations from one .cpp file to another .cpp file (don't move their declarations in .h files, though). So it is conceivable to have 1 .cpp file with all your event handler implementations, and the app will work fine. I do the opposite in one of my projects - I have a TForm with a LOT of event handlers on it, so I move them into separate .cpp files grouped by functionality (yes, I should use TFrame to manage that, but I am not at liberty to change that at this stage of development).
There is a side effect, though - if you try to double-click on an assigned event in the Object Inspector, it won't be able to find the handler's implementation code if you move it.
However, regarding DFMs, every TForm, TFrame, and TDataModule class that is created at design-time must have its own individual DFM. The IDE and the DFM streaming system both expect that. DFM resources in the final executable are identified by class name, and the DFM streaming system reads an entire DFM resource from start to end when loading a DFM into a single root object instance. Besides, the DFM data format does not support multiple DFMs in a single resource stream.
So no, you cannot merge multiple DFMs together.
Or should I just dynamically generate those dialogs during runtime?
Yes. Or just live with letting the dialogs use individiual DFM resources. If your dialogs really are as small on content as you say, the overhead to your executable should be minimal.