hcOPF and XE2 Unit Scope Names

I just installed the newly released XE2 and attempted to compile my current client’s project in the new IDE so I could start using it on a daily basis.

One of the first things I needed to do was compile hcOPF for XE2.  I expected not to have any issues since I am currently using hcOPF with Delphi XE.  Much to my surprise, the compiler kept complaining that it could not find Windows.dcu - an odd error considering Delphi has been a Windows development tool for over 15 years but understandable once you know that Unit Scope Names were introduced in this release to accommodate X platform development and units were reorganized.

Unfortunately, unit names in Uses clauses have to be fully qualified (winapi.Windows in this case) and this means using a whole bunch of {$ifdefs} for XE2 to provide fully qualified unit names.  It’s certainly an ugly solution, but I am happy to say that hcOPF now compiles under XE2 with the exception of the DevExpress package which must wait for a vendor code update.  The latest changes are in the SVN repo.


7 Responses to “hcOPF and XE2 Unit Scope Names”

  1. Peter Says:

    “Unfortunately, unit names in Uses clauses have to be fully qualified (winapi.Windows in this case) and this means using a whole bunch of {$ifdefs} for XE2 to provide fully qualified unit names.”

    …not true. XE2 compiles winapi.windows and windows. Don’t touch your default settings.

  2. Allen Bauer Says:

    While modifying the sources is certainly one way to go, it is not strictly necessary. If you specify the -nsSystem;Winapi;Vcl;Data;Xml command-line switch if you’re using the compiler directly, that will tell the compiler to use those items as prefixes when searching for the actual unit. Windows will be found as Winapi.Windows. From the IDE, you can specify the same list in the compiler options for Unit Scopes. Depending on the project and the configurations in contains, the “upgrade” process should automatically add the default list of unit scopes.

  3. Larry Hengen Says:

    @Allen & @Paul,

    That was not my experience this morning with the release. I will check it again after a good night sleep, but I found even though WinAPI was in the Unit Scopes in the Project Options, the compiler was still complaining about not being able to find Windows.dcu until I explicitly changed the Uses clause. The same thing happened for DBTables, etc.

  4. Tim S. Says:

    Did you ever get the Unit Scopes to work as Allen & Paul describe? I see the same behavior as you. The only way to resolve the units in an existing project is to explicitly put “Winapi.Windows” in the uses clause.

  5. Larry Hengen Says:


    No I did not. I believe there is a bug here but I haven’t had the time to play with XE2 since I tried that initial migration. Until we have an update from DevExpress and I can make it my primary IDE at work, it’s likely I won’t have a bunch of time to re-visit it. Please file a QC item if you can give them more specific information on how to re-produce it.

  6. Patrick V. Says:

    @Allen Bauer,

    Thanks a lot, it’s help me.

  7. Guus Raaphorst Says:

    I have the same issue when building through the IDE on my laptop. I tried adding the scope names to the options set i used, but that did not work. Then, I tried adding the m to the build confifuration of the project I used, but that did not work either.

    Finally, adding the scope names (at least System;Vcl;Winapi) to the IDE options (environment-Delphi options-library node and then the unit scope names field) made my project build correctly.

    It seems that the scope names are not resolved correctly all the time. Funny thing is that i do not have this problem for another project. I also did not encounter this problem on my desktop pc, so my first quess would be that there is some incorrect setting(s) in the .dproj.

Leave a Reply