Here's my problem:
UnitA.pas fails to be compiled as UnitB.dcu cannot be found.
So why don't I just add UnitB.pas to my project? - Because UnitA.pas shouldn't even be part of my project but is somehow contained by another unit. I want to find out, which unit that is.
How can I do that (I am using Delphi XE4)?
Note: I think there was some option in Delphi 2007 to get the desired information in compilation log but I don't remember where it was...
One of my workmates gave me the hint to just rename the units that should not be part of the project. Thus, I get an error in the depending unit. I continued with this until I found the unit reference I need to erase at almost root level.
Related
I'm using the Synapse library in a Delphi project to do some networking.
When I try and use one of the Types that are defined in the external units, i.e: 'TTCPBlockSocket', it has the red underline and says "Undeclared Identifier 'TTCPBlockSocket'".
The files are all in the correct folders and the 'uses' statement can find them and shows no errors.
The strange thing is that I've had an identical setup in another project and there have been no errors in that project.
As a note: I can't install/edit the software/settings, so I can't add any fixes.
This is a well-known bug in Error Insight. It has existed since Error Insight was first introduced in Delphi 2005 or 2006, and still exists today in Delphi XE5.
It's caused by a different compiler being used for Error Insight, apparently, that doesn't have access to the same symbol set used by the Code Insight compiler (the one that helps you find symbols in the Code Editor) or the command-line compiler (the one used to actually compile your code for an application or package). It therefore only uses files that are actually referenced in the project (.dpr) file to locate symbols, and since the majority of files in the uses clause in your code aren't in the .dpr, it can't find them.
There are two fixes (one that is very easy, and one that works but is a pain in the backside):
(The easy one). Turn off Error Insight totally, in Tools->Options, the Editor Options section, Code Insight; just uncheck the box for Error Insight. I prefer this one because Error Insight doesn't work properly anyway, and it avoids the annoyance of having to use the other option every 10 minutes. This is the first thing I do when I install a new version of the IDE and see the red underlines.
(The pain way). Use Project->Add to project for every unit that contains one of the underlined symbols. This adds a reference to every unit to the project .dpr file, which causes it to increase in size drastically. It's a pain because you typically have to do that for every single unit (in my experience, including those that are part of the standard VCL/RTL) that hasn't already been added, and it very quickly becomes irritating. Error Insight doesn't tell you anything that a quick Ctrl+F9 won't anyway, IMO.
I have problem to build my project. I am using delphi 2010.
when i try to build my project this error shows up. "F1026 File not found: 'System.Action.dcu'
I've tried to find solution for this error, but i can't find anything that really fix this.
any idea?
First of all, I am going to assume that the error message actually refers to System.Actions.dcu (as per the question title) rather than System.Action.dcu (as per the question body). It's always best to use copy/paste error messages so that they are transferred verbatim.
You are using code written to target a later version of Delphi. Not only does Delphi 2010 not have unit scope names, i.e. System.<unitname>, but it does not have the Actions unit. If memory serves correctly, unit scope names arrived in XE2 and the Actions unit in XE3.
The code you are compiling has a unit the uses System.Actions. Find that unit and work out where it came from. Then you'll need to work out how to proceed. Can you get a version of code that supports your older Delphi version? Can you port the code to your Delphi version? Can you find an alternative library? Only you can answer those questions, I'm afraid. We cannot give advice at the moment since we do not know anything about the code that is causing you problems.
How can i fix this error and from where I get dxDBGrid file,i'm a new in Delphi,i'm getting the: [Fatal Error] File not found: 'dxDBGrid.dcu'
As others have already told you, that's the file that contains Developer Express's TdxDBGrid. It's quite an expensive product, so before you go off and purchase it, it would be wise to see if you actually need it (I'll explain why I have a hunch you might not in a moment).
First thing to do is do a Find in Files search through all the units in your project, to see which of them lists dxDBGrid in the Uses list in its Interface section. Once you've found the file try and open it and see if the form contains a component of type TdxDBGrid. If it doesn't, remove dxDBGrid from the unit's uses list and try recompiling.
The error may go away, in which case, problem solved. The reason I think the error might go away is that typically, using a TdxDBGrid on a form causes a lot of other units from the DevEx package to be added to the unit, in addition to dxDBGrid, and usually they would appear in the unit's Uses list ahead of dxDBGrid, so if Delphi really can't find the files of the DevEx library, it's surprising Delphi isn't complaining about not being able to find those before it gets to dxDBGrid. So if it uses dxDBGrid alone of the Devex package (other units in their package typically begin with dx or cx), it's possibly only there is a historical hangover. Otoh, if the unit does use other dxXXX or cxXXX units and Delphi isn't complaining about not being able to find their DCU files, it must be finding them (in .DCU or .PAS form) ok.
If you're still stuck, post the Interface section of the unit which provokes the compiler error you described.
I am writing a designtime package in Delphi 2007.
I decided to move some event type declarations into their own Eventsunit so they can be used in multiple units. When I did the compiler started complaining Undeclared identifier: 'Event Name' in the units where these events were originally declared. The type declarations are all in the interface section of the Events unit and I have added the Events unit to the other units' uses clause but its like the compiler is completely ignoring the Events unit.
The IDE has no trouble finding the declarations when you CTRL + Click in the type name from another unit. Hovering the mouse over the type name displays the unit its declared in along with its parameters. Even the usually craptastic and paranoid Error Insight feature of the IDE doesn't see a problem. Only the compiler complains about it.
I tried reproducing this problem in another, simpler package project to try to isolate it but I can't reproduce it.
Has anyone else seen this behavior before and is there a work around?
I had already tried all the common sense suggestions like making sure the file was in the project and in the uses clause of the other units.
Since no one has posted a solution I tried Ken White's and Wouter van Nifterick's suggestions.
closed the project and restarted the IDE - no change
Searched every drive on my system for Events.pas or Events.dcu - the one in my project was the only one.
The only thing that worked, and I have no idea why, was to rename the Events.pas to something else. I renamed it using the Project Manager and recompiled. All the Undeclared Identifiererrors simply disappeared. I renamed it back to Events and the errors came back. Who knew?
Just out of curiosity I did a text search over every pas and inc file on my system to see if Events was used as an identifier somewhere (I know it shouldn't make a difference but... ya never know). Nothing. No variables, types or functions called Events.
As a sanity check I created a simple project with a handful of units, one of which was called Events with a few type declarations. All the other units included it in their uses clause. The compiler had no trouble resolving the type identifiers. I have absolutely no clue why it choked on the Events unit in my other project.
Update
I finally figured out why I was getting this error. The package I was writing used the open tools api(OTA) so it required the DesignIDE package. DesignIDE is provided only as a precompiled dcp and bpl so the source is missing for everything except the handful of interface units exposed as extension points for the IDE. It turns out that one of the hidden units compiled into DesignIDE is called Events. I did not discover this until I migrated my package to a later version of Delphi and started getting E2200 Package 'designide' already contains unit 'Events'. This error message did not appear in Delphi 2007.
My attempt to isolate the problem in a simpler package could not reproduce it because I had excluded the DesignIDE package from it's dependencies, not realizing that it was the source of the error.
We have the following in our codebase, in a component file:
{$IFDEF ADO}
FDatabase : TADODatabase;
{$ELSE}
FDatabase : TODBCDatabase;
{$ENDIF}
The reason is that for various legacy applications, one or the other type of database connection and set of classes is to be used.
However, while configuring a new machine, it seems that our conditionals aren't taken into account. In the project settings, it says "ADO;DEBUG", and yet it compiles the above code with the odbc type instead.
The odd thing is that it isn't consistent. Two different units built as part of the same project uses separate settings. In other words, in one place our conditional is visible, in another it is not.
The file that compiles wrong does not have any {$UNDEF or similar directives, nor does it include any files.
What am I missing here?
Solved (ugh): Right, Delphi is just being boneheaded, or whatnot.
We found these:
I get “F1026 File not found”, OR some compiler options are not passed to the compiler from the IDE.
Configuration='Debug' Platform='BNB'
Which both mention the "Platform=BNB" setting. By enabling the diagnostic output, we see that exact value. So we try to override it per the articles, no luck, still BNB. Then we go to the project settings, turns out it can be overriden there as well, so we do that too, still no luck.
Turns out the Delphi installer, or whatnot, has added a "Platform=BNB" environment variable on operating system level, removing that, restarting Delphi, and all is well.
Well, as well as can be expected. We still have to use Delphi though.
You should always make a "build all" when you change those conditions.
It could be that one unit is actually not re-compiled. Check the following:
Is the .pas file included into the project?
Is there another file (.pas or .dcu) with the same name in the search path? It's possible the IDE sees a different file than the compiler.
Is the file actually compiled? Compare the timestamps of the .pas and the .dcu file.
Do you compile for another platform? Some compiler options are not passed unless the platform is "AnyCPU".
Whenever I encounter problems like this I brute-force delete every .dcu file in my project and component folders just in case the "Build all" doesn't remove all stale .dcus. The following recompile either solves the problem or reveals if any wrong .dcu was used.