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.
Related
I'm using C++Builder 10.4.1. I've migrated a simple project containing 3 forms. The main form contains a TDriveComboBox. When I try to compile I get these errors:
[ilink32 Error] Error: Unresolved external 'Vcl::Filectrl::TDriveComboBox::' referenced from (then it lists the path to the main form's OBJ file)
[ilink32 Error] Error: Unresolved external '__fastcall Vcl::Filectrl::TDriveComboBox::GetDrive()' referenced from (then it lists the path to the main form's OBJ file)
I've even tried to delete the TDriveComboBox and replace it, but that doesn't help.
What's the problem and how can I fix it?
I would:
delete all temp files (obj,exe,tds,...)
add new temp TDriveComboBox on form with this problem
compile and run.
If that does not help then sometimes manually #include VCL header containing the component into form *.h file helps reset the compiler/linker so search the VCL inc folder for TDriveComboBox In mine system its in here:
c:\Program Files (x86)\Borland\BDS\4.0\include\vcl\FileCtrl.hpp
So add something like:
#include <FileCtrl.hpp>
or
#include <vcl\\FileCtrl.hpp>
into your form *.h file... but even this sometimes fail. In my experience the problem lies in the project file (*.bds, *.bdsproj, ... or whatever extention the newer versions got) so its a good idea to backup it while the compiler works as should... As it sometimes corrupt it self especially for big projects.
Sometimes also helps if you move:
#pragma hdrstop
line to different locations (few lines down or up). If you're lucky it can also reset the compiler/linker after which you can move it to original location. However this helps only occasionally (like 1:20). And you also need to try few locations
In case nothing works just create new empty project and copy the forms and stuff into it and add it to project... Each form has 3 files (*.h,*.cpp,*.dfm) and do not forget to add to your project whatever you need (DLL *.lib,...) if its not linked directly with #pragma link for all the 3th party custom stuff your app uses
Once (also after migration from BCB5 to BDS2006) even this did not help for one of mine projects. I was forced to create also the forms (with all the components but without functionality just place them on forms) and then copy the stuff from old App... However if you got too many components it will be a pain in the ...
I have found for most of these problems created by the ide in converting my 10.3.3 projects to 10.4.1 can be solved by an annoying process as described below:
open the form.
on design tab, switch to text view.
switch to form veiw.
under project, recompile just the form.
now run project.
This has solved most of my unresolved's except _CG_*.
I´m using Delphi 7 and have a new unit which I would like to use in my project. I already compiled the new. When I try using this unit in my project by adding it to the uses clause, it comes out the an error saying .dcu file not found. I also tried putting the full path of the file in the uses clause, but that still didn't work. I have already search for the respective .dcu file and it was nowhere found. It seems it was not generated... Can anyone give a hint how to solve this? Thanks, Ana
Delphi is not going to find your new unit by only adding it to the uses clause. You also have to add it to the actual project. There's no need to keep track of the .dcu file(s), as they're already compiled and cannot be modified. If I remember right, in Delphi 7, go to Project > Add Existing File > Pick your .pas file. Adding a unit to the uses clause presumes that the file is already included somewhere that Delphi can find.
I have a .BPG project which has a collection of .DPR project files.
Opened a .PAS file
I changed some line of code in a .PAS file of an project.
Saved it
After changing the source code, I tried COMPILE on that project.
First it says "Compiled" successfully.
Now I see the same .PAS file, the changes were lost. Codes changed at step 2 was lost. It is having the previous code only.
The behavior is same for BUILD too.
Anyone knows about this problem?
Thanks in advance.
Update
One more hint:
.DPR Project Name is XX.dll In IDE, there is one file with name XX_TLB.PAS in that project. In this file only I tried to change some code, which got reverted after compiling/building. Now I tried to rename this file, which gave me a error message
Type Libraries must have the tlb extention.
Also can the .DCU and .PAS files be in the same directory? I entered this directory (where both .PAS and .DCU files exist) into the directories list under "Tools->Options->Delphi Options->Library - Win32"
XX_TLB.PAS files are protected files. Do not edit such files directly. In fact there is note on top of the file warning you from editing the file.
They are regenerated each time the type library is refreshed.
See Code Generated When You Import Type Library Information.
This refresh could be done by the IDE each time you compile/build your dll.
You will never edit this file because of the dependencies of a type library and registered com objects. Either you change the com object itself via the type library editor, or create a new unit that interacts with your ActiveX class.
The Delphi IDE doesn't undo changes, as a general rule. There's notable exception. When you create an empty event handler, and then save the source file, the IDE will remove that event handler. Perhaps that's what is happening.
The other possibility that occurs to me is that you have multiple copies of the file. I've known the following to happen:
You create a package containing Unit1.
You install the package.
You then make another project that contains a different Unit1. Perhaps a copy of the file in a different location, so that it looks like the same unit.
You then modify the copy of Unit1, but the IDE sometimes prefers to open the file from the package.
The bottom line is that beyond deleting empty event handlers the IDE won't undo your changes. So it seems extremely likely that you have multiple copies of the file. To get to the bottom of this, you need to get the full path to the file. In the IDE, hover over the tab with the filename and the IDE will display the full path in a hint. I suspect you'll find that you have two distinct files.
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
I am trying to recompile/rebuild an old application program developed on Delphi5. I used the same Delphi5 software on an XP computer.
I did some minor corrections to the codes of a couple of forms and units. When I recompile using the .dpr file it comes with a fatal message: File not found System.pas
I added in .dpr file on the link path to this file BP folder. No success and the same message. Any clue will help.
Probably Library Path is broken after running some buggy component installer. In modern IDE's look for Tools -> Options -> Library -> Library Path from main menu (should be slightly different for Delphi 5).
System.dcu file lives in $(BDS)\Lib path for Delphi 2007.
The "File not found System.pas" error often isn't really because it can't find system.pas. It's some other problem that manifests as this error.
It can be:
Duplicate Path entries in the Library Path.
Too many entries in the Library Path - I think the limit is 99.
Path to a package in Library Paths too long.
Path to a package in Library Paths corrupt.
Environmental Variables not set correctly.
and possibly more if you Google "system.pas not found"
Marjan is right.
But also add ${DELPHI}\LIB\OBJ
If you still have a dcc32.cfg with the project, or a .cfg with the project, open it up to see if the settings in there are correct. Otherwise delete the .cfg or edit it to reflect the proper path to the bin and bin\obj directories.
A .dpr file is the main project file for a Delphi 2,3,4,5,6,7 project.
You have not given any details like WHAT WAY OF BUILDING SOMETHING of delphi you're using (the code is Delphi 5 level code, but you are not telling me for example, if you built the project inside the Delphi IDE or from the command line compiler DCC32), and what other files you have installed. You haven't mentioned if the library paths and so on are configured (either for the IDE, or for the command line environment, both of which are separate tasks).
An inability to find System.pas suggests to me that you might be running the command line compiler (Dcc32) instead of the IDE to build the project, and you have forgotten to mention that. That usually means you have to set up the Options (dcc32.dof) file for Delphi, so that command line building with Dcc32 can work.
What exactly do you mean by "When I compile with the .dpr file"? Instead of making people guess, show the commands you typed, exactly, and the error message, exactly. If it helps, use screenshots or text grabs.