0

I have a library (FFVCL) without source code (only DCUs). It contains a form called TfrmAbout. My program also contain my own TfrmAbout form (totally different thing but with the same class name).

When I compile, I get this hint:

H2161 Warning: Duplicate resource: Type 10 (RCDATA), ID TFRMABOUT; File C:\Packages\Controls\FormAbout.dfm resource kept; file c:\Packages\FFVCL\DCU_DXT4\Win32\FFAbout.dfm resource discarded.

In other projects, MY dfm is discharged, and the other one (FFVcl) is kept.
In this case, the app crashes with a nasty error during sreaming: Label1 not found (Label1 is a label in MY form). Why is the compiler behaving this way?

Yes, I could rename my class from TFormAbout to something else, but I want a solution that accepts both forms as they are (for example, what if BOTH forms are in DCU files and I can't rename the class)?

Note: this question is different from H2161 Warning: Duplicate resource: Type 10 (RCDATA) because that one asks about dres files explicitly liked with {$R}.

sepp2k
  • 363,768
  • 54
  • 674
  • 675
Gabriel
  • 20,797
  • 27
  • 159
  • 293
  • Why not simply rename YOUR Form to avoid this ambiguity in the first place? You should not have 2 Forms with the same class name in your project. Their DFMs will clash with each other, as you are discovering. – Remy Lebeau Mar 17 '22 at 19:56
  • @RemyLebeau - Hi. Looks like we wrote in parallel :) I just explained why not (in parallel with you) because I imagined someone will ask the question :) I think that is a solution but a bit extreme. – Gabriel Mar 17 '22 at 19:59
  • 1
    DFMs are stored in the final EXE's resources by class name without regard to Unit names or Namespaces, so you CAN'T have 2+ Forms with the same DFM class name in the same project, as the final EXE will only be able to keep 1 of the DFMs, resource names can't be duplicated. Thus, you simply don't have a choice, you MUST rename one of the classes if you intend to use BOTH Forms... Well, that is not *entirely* true, I suppose you could override a Form's constructor to load its DFM resource using a different name. But that is a lot more work to setup and execute, I'm not sure how feasible it is. – Remy Lebeau Mar 17 '22 at 20:05
  • "without regard to Unit names or Namespaces" - This is what I hoped to be able to "fix" somehow..... – Gabriel Mar 17 '22 at 20:06
  • There is no way to tell the IDE/compiler to include a Form's unit name/namespace in the DFM's resource name in the EXE. This is a long-standing issue in Delphi, dating back to when DFM's were first invented. – Remy Lebeau Mar 17 '22 at 20:07
  • 1
    As @RemyLebeau stated the forms are stored into the executable code under the classname - so you can't store two resources in the same executable with the same access details. That's how the Windows executable formats work. However you **absolutely can** compile the library into a package (.bpl) and it will then load it's own resources from the .bpl (which is loaded as a dll) and your code will load your resources from the .exe. Some Delphi developers want to compile monolithic exes (no runtime packages) but in this instance runtime packages will enable you to do what you want. – Rob Lambden Mar 19 '22 at 12:34
  • @RobLambden & Remy - Thanks. – Gabriel Mar 21 '22 at 07:16
  • The author of one of the libraries accepted to change the class name (TAboutForm) to something less general. – Gabriel Mar 21 '22 at 07:16

0 Answers0