0

Many units, both in free and commercial libraries, as well as from Embarcadero itself, do not contain full unit names in uses section such as Winapi.ShellAPI. We tried to compile a program with madexcept, which has ShellAPI in uses, as well as third-party components with PD.ShellAPI with Windows in the Unit scope names settings and the path to the PD.ShellAPi at the end of the Library path. However, it's not possible to compile the program because it always finds PD.ShellAPi and prints a lot of errors like Undeclared identifier: 'shell32', because it can't find it.

It helped to modify the uses in the madexcept from ShellAPI to Windows.ShellAPI, but fixing uses in third-party libraries is definitely not a sustainable solution. For some of us it worked even after modifying some settings, I don't know which ones yet. However, for some libraries from Gnostice containing Stream and the other one containing PD.Stream, but with Stream in uses it never found PD.Stream.

Is it possible to define the unit search order, like to first search within certain directory including Unit scope names from the settings and only then continue with other paths? Or another way to avoid similar problems.

Triber
  • 1,525
  • 2
  • 21
  • 38
  • 1
    Modify the third party library use clauses. I don't think you have a choice. You'd need to be able to modify the unit scope name search order at the granularity of the using units, and I don't think you can. I guess the only way you could would be to put conflicting libraries into different runtime packages. – David Heffernan May 19 '20 at 13:21

1 Answers1

0

This answer is taken directly from http://docwiki.embarcadero.com/RADStudio/Tokyo/en/Programs_and_Units_(Delphi)#Unit_References_and_the_Uses_Clause:

The order in which units appear in the uses clause determines the order of their initialization and affects the way identifiers are located by the compiler. If two units declare a variable, constant, type, procedure, or function with the same name, the compiler uses the one from the unit listed last in the uses clause. (To access the identifier from the other unit, you would have to add a qualifier: UnitName.Identifier.)

Matthias B
  • 404
  • 4
  • 11
  • This is a different problem, it describes a situation where the compiler decides which version of variable, constant, type, procedure, or function to use if multiple units containing it are used. It does not address how to search for units if there is more units with the same name or there is no namespace specification in uses section which leads to ambiguity. – Triber May 20 '20 at 09:37
  • Oh, I see now. Indeed. After thinking a bit about it now, I think David H is right. The system would need to have different search orders depending on "from where the search is started". That would be possible, but a bit messy, and as far as I know it does not exist now. The natural solution is to specify what you want to use, specifically enough. The 3rd party libraries should have done it better - and if they don't, then you need to do it for them. – Matthias B May 20 '20 at 14:11