When using more than one .dpr in the "included files list", all units seem to be addressed from the second project's directory as working directory. Yet, the other .dprs have different working directories; thus, all relative path references fail, including the units that are directly part of the other .dprs.
Delphi 7, DCTC 0.22.0.854 and .861 (nightly 15.4.09)
e.g., Included Files List:
..\Project1\Project1.dpr
..\Project2\Project2.dpr
Project2.dpr contains Unit2a.pas, while Project1.dpr contains Unit1a.pas.
The file <full path="">\Project2\Unit1a.pas is not found. Which is combines the second projects working dir with the first projects unit.
Exception is raised "Cannot open file "<full path="">". <german exception="" msg="" for="" file="" not="" found="">."
With three projects, the second one again seems to be used as working directory.</german></full></full>
Anonymous
DelphiCodeToDoc was designed to generate documentation from ONE project only. Including multiple dpr files can cause trouble as unit filename can be the same, even if the content is not identical.
So, tell me why you really need this functionality, and how you want it to be presented in the documentation. Maybe you also want different configuration for each dpr files ?
I can't say at this moment if I will work on this item, but I need to understand how critical it is.
I can understand that it is not meant to work ... maybe put some information in the help that the "list of included files" should only be used as a list for .pas files, not for project files. I was not sure wether this was a supported scenario.
Or change the UI to either select a project file, or a list of .pas.
It's not really that important, the main reasons was to make the maintenance of the project file(s) easier. Just one DCTC project file for multiple dpr -- less prone to using different settings on different delphi projects. And it only takes one run of the tool to generate multiple docs. Yet, using the cmd line to generate the documentation in one go for all projects should achieve the same.
Units would have to be addressed by full path (canonical and case-insensitive ...) to distinguish them, and path or hash codes added to the generated file names ... I can see that this would be a lot of trouble. Just comparing to javadoc (full package names) and SandCastle/.Net (hash codes) ...
Doesn't matter. More important stuff ;-)
ok, priority lowered.