H2161 Duplicate resource [Can a VCL project have 2 forms with the same class name but different namespaces?]

Question

I tried creating 2 forms with the same class name in 2 different namespaces

FirstNameSpace.ExampleFormName.TExampleFormName
SecondNameSpace.ExampleFormName.TExampleFormName

although this compiles, I get the following hint

[dcc32 Hint] H2161 Warning: Duplicate resource: Type 10 (RCDATA), ID TEXAMPLEFORMNAME; File FirstNameSpace.ExampleFormName.TExampleFormName.DFM resource kept; file SecondNameSpace.ExampleFormName.TExampleFormName.dfm resource discarded.

and the program crashes when referencing TExampleFormName.

It looks like there isn't enough information for the linker to work correctly.

Is there any way to make this work?

Arras

Would it work if you changed the second TExampleFormName to TExampleFormName2 to stop the resource conflict, and added type TExampleFormName = class(TExampleFormName2); – Disfigurement

I tried doing the cast as suggested. The program compiles without hints. However the behaviour at runtime is quite strange. If ExampleFormName1 & ExampleFormName2 contain any components with the same name: the program crashes with an EComponentError exception - A component named whatever already exists. If ExampleFormName1 & ExampleFormName2 contain no components with the same name: the components from BOTH dfms are displayed on single form. – Arras

The conflict issue is more to do with Windows than Delphi. Behind the scenes the application registers the form with Windows and Windows does not recognize namespaces like Delphi does. – Furniture

Answer 1

No. As is indicated in the nature and content of the error, the class-name reference in the associated form files (.dfm) is not namespace qualified and neither are the corresponding resource ID's.

Form class-names must be unique within/across an application.

Similarly, class names of components referenced in a DFM (including controls placed on the form) must also be unique since these also are not namespace qualified.

To promote/ensure unique component/control classnames, a system of prefixes has been adopted by vendors and component developers. That is, Every class produced by a vendor or in a suite of components etc will share a common prefix in addition to their usual name.

For example, if a company called ACME were to provide a library of enhanced, standard UI controls, they might name them:

TAcmeEdit
TAcmeButton
TAcmeListbox
etc

In order to distinguish them from the standard (non-prefixed) VCL controls or from other vendor controls (using a different prefix).

The Delphi Prefix Registry is a community run/supported web site maintains a list of these prefixes (of most use to developers of control/component libraries to ensure they pick a prefix that is not already in use).

I'm not sure how FMX application resources are handled and it may be possible in that case. But just because I don't know that it doesn't work doesn't mean that it does.

Ezzell

And I wonder why? It should not be too hard to give different form classes different names. Why should they have the same name? – Hevesy

@RudyVelthuis - perhaps because when the VCL/resource linking mechanism was devised there were no namespaces so this was not an issue. This was never fixed when namespaces (or at least just dotted unit names) were introduced with Delphi 7. The problem extends - or used to - to classnames of any components/controls on a form, which is why the system of prefixes became so important, and the Delphi Prefix Registry. Fixing it now would by definition not help any existing code and the VCL/Windows isn't sexy any more. If it's not a problem on Android/iOS then it's not a problem, period. :shrug: – Ezzell

That is not what I asked. Give your forms different names and there is no need for namespaces in DFM files. I am not talking about component names. – Hevesy

@RudyVelthuis sorry, my bad. Although your wondering "why" seemed to be asking why they "had to be unique", hence my confusion. But even if you weren't talking about it, the problem is a general one affecting all component class names (a form is after all just a specific type of component). Giving forms different class names is just a contextual example of uniqifying a class name. Component class name prefixes is the generalised, systematic and unavoidable technique for avoiding the general problem. – Ezzell

In answer to Rudy. I used forms as an example, the real world use is different component types. I distinguish between component types with suffixes - e.g. _data.pas, _form.pas, _report.pas. If namespaces worked better I could have ditched the suffixes – Arras