I'm using parallels VM and recently had my code in Dropbox contained within the VM. Dropbox was quite problematic in that it is really slow if you have a lot of files. Since Parallels happily shares folders from the HOST, and one of those folders is the HOST Dropbox folder, I started using that drive (essentially \mac\Dropbox mapped as W:). All goes well, the VM is much faster and I can easily access the pas/dfm files.
HOWEVER, when I build the project, the compiler complains that it cannot find DFM files (eg. about.dfm, login.dfm etc). The various DFM files are all there and the compiler complains of different DFM files, ie. one build it will be login.dfm and about.dfm, the next it will complain it cannot find Waiting.dfm. All of the DFM files are there, readily editable in the IDE.
The only thing I could try, other than constantly trying to build the project, was to put the path of the project into the library. This made no difference.
In another project the compiler cannot find the project resource (res) file. And, of course, that file is also there.
[dcc32 Error] E1026 File not found: 'EMPSecureInitialize.res'
[dcc32 Error] E1026 File not found: 'EMPSecureInitialize.res'
[dcc32 Error] E1026 File not found: 'About.dfm'
[dcc32 Error] E1026 File not found: 'Login.dfm'
[dcc32 Error] E1026 File not found: 'EMPSecureSlideShow.dfm'
[dcc32 Error] E1026 File not found: 'About.dfm'
[dcc32 Error] E1026 File not found: 'Login.dfm'
[dcc32 Error] E1026 File not found: 'EMPSecureSlideShow.dfm'
Projects with the source on a local drive, build without issue. Projects with source on a network (Parallels Host) drive arbitrarily do not find DFM or RES files. Those files are always and readily found when using the IDE, ie. click Design and the form appears.
I could understand if this was a consistent fault, but it is not 100% repeatable, sometimes the build works as expected. Is there some sort of weird timing or path construct that the compiler uses?
While it is practically impossible for anyone to reproduce your precise environment to reproduce this issue, I have a very strong feeling the issue is with a limitation in the number of concurrent files that can be opened at a time. At least on Windows, when a folder is shared, it has the ability to control the number of concurrent connections.
Imagine how the compiler works. It needs to open numerous files rapidly to read their contents and build DCUs out of them. First, the PAS files are loaded. Then, those which depend on additional files, such as DFM or RES files, get those loaded. Then all gets linked together to produce an output. That's a lot of files the compiler needs to open at the same time.
So there's likely a way to control and increase the number of concurrently open files through the Parallels virtualization. This doesn't seem to be an issue with Dropbox.
Related
When I tried to compile one of my BPL files, I get an error:
dxGDIPlusClasses.pas not found.
I double checked the unit file exists on the hard drive.
I also added $(BDSCOMMONDIR)\Dcp to the DCP Output directory, and $(BDSCOMMONDIR)\Bpl to the Package Output directory. The runtime package containing the unit was also added to the BPL.
I searched online for answers, foound one suggestion to enable Build with runtime packages under the Project Options, but when I checked I dont have that option.
Does anyone know how to solve this?
The error message indicates that either:
the compiler can't find the source file it needs for the unit.
the compiler found a .dcu file compiled with a different version of the compiler and needs to recompile it.
.dcu files are not compatible across compiler versions (with the single exception of D2006->D2007), meaning that every new version release of the compiler means all your source needs to be recompiled in order to be compatible with it.
You need to add the path to the source to Project->Options->Directories and Conditionals->Search Path so it can find the source code it needs.
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:
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
Verified there is no difference between these paths between the DPR and DPROJ files
Installed all the latest updates and the IDE FixPack (actually gave me new problems)
Monitored file's access with Process Monitor
Filters: process name equals BDS.exe; Path ends with TestPackageUnit.pas
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
Tried with designtime-only, runtime-only, and designtime/runtime combined
Tried with component registered and unregistered
Tried with directory in library path and not in library path
Removed about 20 unnecessary entries from library path to make it shorter
Moved directory to top of library path
Verified there is no DOF file associated with project (That I think is from older versions)
Restarted IDE and computer number of times
Cleaned up compiled and temporary files from project, including BPL and DCU files
Changed strict private to just private and even public
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.
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.
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
We have a modified menus.pas.
At
uses ...,Controls,...;
The compiler raised a fatal error:
[DCC Fatal Error] Menus.pas(*): F2051 Unit Controls was compiled with
a different version of Menus.TPopupMenu
tried:
deleted all dcu in the project.
build
build all
tried adding the file to library path which leads to add db folder(from vcl too) and then to
[DCC Error] jpeg.pas(872): E2065 Unsatisfied forward or external declaration: 'jpeg_save_markers'
which is a dead end.
deleted the controls.dcu (all 3) and the delphi did not know automaticaly to recompile them, instead reported that controls.dcu is missing.
Here is how I handle modifications to VCL source files:
Make a copy of the file in your project structure. Either add the file to your project, or make sure the search path finds your modified file.
Make modifications, but only in the implementation section. You are not able to modify the interface section if you use any other units that themselves use the unit you are modifying.
Explicitly set the compiler options at the top of the modified source file. Use default Delphi options, as found by pressing CTRL+O O in a default vanilla project.
I'd guess that one of the final two bullet points is what is tripping you up.
In Delphi XE7 (and below) themes and styles are totally unusable.
So, I patched the file ( Delphi XE7\source\vcl\Vcl.Themes.pas ) add it to the project file, compiled it and got a DCU. I replaced the old DCU ( Delphi XE7\lib\win32\release\Vcl.Themes.dcu - same for "debug" folder) with the new one. Everything works smooth now. I don't even have to link the PAS file to my projects.
I have two Delphi runtime packages. The SecondPackage includes FirstPackage in its requires clause. One of the other developers recently added several new files to the first package.
Now when I compile the first package I don't have any errors but when I compile the second package I keep getting:
[DCC Fatal Error] FirstPackage.dpk(91): F1026 File not found: 'SomeFile.dcu'
SomeFile is already contained in FirstPackage but re-adding it to FirstPackage moves SomeFile to the end of the Contains clause and gets me:
[DCC Fatal Error] FirstPackage.dpk(91): F1026 File not found: 'SomeOtherFile.dcu'
I can continue re-adding files until I'm blue in the face and the result is always the same. The first file in the contains clause cannot be found when SecondPackage is compiled.
I've tried deleting all related dcus, dcps and bpls manually and rebuilding but to no avail. Any ideas?
Grrr! Dang you Delphi IDE! Quit messing with the library path. If I wanted to add an entry I would have done so.
Apparently if the project type is a package and you add a file to it Delphi gets a little trigger happy and adds the file's location to the IDE's global library path. Removing the unnecessary entries allowed the packages to compile. Why these entries prevented one of the packages from compiling in the first place is an other matter.
I have a project let's call it Yellow.dproj, which I saved as Blue.dproj, to make some changes. There must be some COM/DCOM related code in this project, but I can't figure out where.
The error I am getting when I try to build Yellow.dproj is that it can not find a type library (TLB) file: "E1026 File not found: ". The file it can't find is MyAppName.tlb. There is a MyAppName_tlb.pas file, which I have tried adding and removing from the project, either way I get this error.
I think I probably have to go into that TLB file, which I don't really understand, and rename a bunch of junk in there, because it is dependant on the name of my application. This is something that happens to you, I suspect, when you use COM/DCOM and type libraries in Delphi (Delphi 2010). You can't just rename or save-as and build a new project again.
What do I do to fix this unit up?
Do you have {$ *.TLB} in your project source?
The * is the project name, so the TLB file has to match the name of the project - perhaps the name of the tbl was not changed along with the project.