4
votes

I have a component package in Delphi XE2 version 16.0.4429.46931, both a run-time and design-time package together. This package has existed for over a year, and the file/folder structure has always been the same. I keep all the units in a dedicated Source folder from the root, and the actual packages in a Packages folder in the same root. So the packages are found in \Root\Packages\ and units are found in \Root\Source\.

Today, after building the run-time package, I was going through the hints and warnings. One of the warnings was this:

[DCC Warning] Inno.TimeChart.pas(1): W1025 Unsupported language feature: 'class constructor'

The warning its self is not what worries me. The problem is when I double-click this warning, I get an error message from the IDE:

IDE Error Message

The one thing which I immediately noticed was that it is not looking in the Source folder, but rather directly in the Packages folder. Somehow, the IDE is expecting that the unit be in the same location as the package. Ever since I created the package over a year ago, I have never changed any of the library paths, locations of files, or structure of the package.

The file does exist, but in a different place than it appears to be looking. The file has never been saved in the folder with the projects, and in fact nothing other than the package projects themselves have ever been saved in the Packages folder. This all resides in the Source folder, but the IDE seems to think otherwise.

Why would the IDE think this file is in a different folder? All the other hints and warnings related to the same unit work just fine when I double-click them, but not this one.

EDIT

I've created a new test package to troubleshoot this issue.

Root\TestPackage.dpr
Root\Source\TestPackageUnit.pas

The specific piece of code which is causing this compiler warning is in this class:

type
  TMyComponent = class(TComponent)
  strict private
    class constructor Create;
  end;

When I compile, using Process Monitor, I see the IDE is searching in 30+ different places for this file (of course failing), it looks like it's searching in every library path, rather than in the one place the package says it's at.

Things I've Tried

  1. Verified there is no difference between these paths between the DPR and DPROJ files
  2. Installed all the latest updates and the IDE FixPack (actually gave me new problems)
  3. Monitored file's access with Process Monitor
    1. Filters: process name equals BDS.exe; Path ends with TestPackageUnit.pas
    2. Result: "NAME NOT FOUND" --> Desired Access: Generic Read Disposition: Open Options: Synchronous IO Non-Alert, Non-Directory File Attributes: N ShareMode: Read, Write AllocationSize: n/a
  4. Tried with designtime-only, runtime-only, and designtime/runtime combined
  5. Tried with component registered and unregistered
  6. Tried with directory in library path and not in library path
  7. Removed about 20 unnecessary entries from library path to make it shorter
  8. Moved directory to top of library path
  9. Verified there is no DOF file associated with project (That I think is from older versions)
  10. Restarted IDE and computer number of times
  11. Cleaned up compiled and temporary files from project, including BPL and DCU files
  12. Changed strict private to just private and even public
3
Hard to say, maybe your package source does not contain the path to this source file in contains clause, maybe you need to restart IDE. Sure IDE should find source files if it compiles them. - kludg
Check it! Log what folders are actually checked for the file. I had experience when Delphi could not build my BPLs into $(OutputPathVar) - but restart fixed it. And i saw issues where installers enforced 64-bit paths into 32-bit Delphi environment, deleting original paths. There may be a lot of troubles, but logging would at last give you soem idea what is really happening. - Arioch 'The
SysInternals.com filters: process name, equal, BDS.exe (or how your delphi is called); path, ends with, your file name. On the toolbar press filesystem operations button and unpress all the rest - Arioch 'The
Jerry, what is the structure of the DPK, are you using relative paths that point to the units? - whosrdaddy
In the worst case you could met an ICE - internal compiler error. I met situations when Unit1 was used by Unit2 and Unit1 triggered ICE. but it was reported against head of Unit2 instead. But that was not about warning but about clear ICE. BTW, the very text of warning seems strange to me. In which condition class constructors might be unsupported by XE2 ? C++ headers emitting ? Extended Syntax shut off ? the very text or the warning makes me curious - Arioch 'The

3 Answers

3
votes

I do run into such problems when the delphi search path list is too long. I could always help myself in moving the relevant directories more to the front, i.e. up in the list.

1
votes

Check that the file has not been added to the project file (dpr or dpk). Project - View Source will display the file.

If this isn't the case, try searching all the files in your project for the file name and see what turns up.

1
votes

Found this on another website:

There is another QC that is probably linked to your problem. http://qc.embarcadero.com/wc/qcmain.aspx?d=87693

Go to Project Options -> Delphi Compiler -> Output C/C++ and under C/C++ output file generation select Generate DCUs only.

Dalija Prasnikar

Source: http://codeverge.com/embarcadero.delphi.general