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.
Related
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.
I have all the files needed to open the unit and code but I can't make any changes or compile because the Project.dproj and Project.dpr files are missing. However, I have the .exe file. Is there any way by which the aforementioned files can be extracted from the .exe file?
If you have all of the source files, meaning the .pas and .dfm files, then the first thing I'd do is add them all into a new project and try to compile it. It'll either work, meaning you've got everything you need, or it will generate errors.
There would be three kinds of errors:
The first is the most likely -- the forms might use components that you don't have installed. This will be obivous if you try to open the forms in the IDE. If they open without fanfare, GREAT! If you get a warning box saying "Cannot locate component: remove references to it?" or something like that, then you're probably hosed.
The second is version-specific errors -- stuff that's old and crufty and no longer supported by the language.
Third, the program may use run-time libraries that you don't have.
The compiler adds RTTI metadata, including unit names, when it builds, and if you know about how the RTTI tables are laid out it's possible to extract this. The unit list is the principal component of the DPR file, but it takes some serious work to access it and I'm not aware of any tools out there that read the RTTI tables that have been kept up to date beyond the Delphi 7 era.
As for the .dproj file, you're out of luck. That doesn't actually contain any code that gets "compiled in" to the EXE; it's a set of build instructions for how to produce the EXE. But if the Delphi IDE doesn't have one, it can generate a default .dproj from the .dpr, if you can produce that.
I'm curious, though. How did you obtain the .pas files but not the .dpr?
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 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 a Delphi 5 application, that is built without runtime packages, dlls or external resources (i.e. a single executable). when we install it on a clients PC we get the following error messages:
Class TListView not found
or
Class TImage not found
We have installed it on dozens of PCs before without incident, but this latest install is problematic.
The target PC is a fresh install of Windows XP (Service pack 3) with no other software installed.
It does not complain about all of the classes however just one or two. for example TPanel/ TForm/ TEdit are all OK.
Can anyone think what is causing this?
EDIT
The exe on the new PC is on 30 or so other PCs that I know of, ranging from windows XP Sp1,2,3, Windows Vista and Windows embedded. both old and new PCs were installed with an old version and then updated with the newest version. The only difference is that the version jump was higher for the latest install.
This is typically an error during the streaming of a .DFM. Usually this error occurs with TLabel components because many folks remove the TLabel fields from the form or frame in order to cut down on the clutter and reduce the instance size of the form. The common and confusing mistake they make, however, is that in their over-zealousness, they remove all TLabel references. That is when bad things start to happen. Let me run down how the streaming system locates a component's class.
Remember that the class reference in the .DFM is just a string. The streaming system has to convert this string into a class reference (TComponentClass). There are two mechanisms that the streaming system uses to do this. The first one is very simple and involves a global list of class references. You can call RegisterClass or RegisterClasses to explicitly make the streaming system aware of it. The second is much more subtle and not very well known; in fact it is all part of the "magic" of Delphi :-). When the compiler builds the form, all the fields that represent the components on the form are processed and an internal table is built as part of the RTTI or metadata for the form/frame/datamodule itself. This table contains a list of references to all the individual component types represented by the component fields. So even if a component is not in the global list, it can still be found by scanning through this compiler generated table. That is what the Classes.TReader.GetFieldClass() method does.
Back to my TLabel example, this problem is easily fixed by simply ensuring that at least one of a given component type has a field. So as long as there is at least field of type TLabel, all the other TLabels will load just fine. So in your case, make sure the TListView or TImage fields haven't been deleted.
Re0sless,
I suggest you open and close every form of your application and do a fresh build after that. If memory serves me well, that was the solution when we encountered similar problems.
You might also take a look at DFM Check to open and close all your dfm's automatically and at CnPack to help you clean your uses clause.
Regards,
Lieven
I think Lieven is definitely on the right track: simple base classes not being found during runtime are a Delphi (linker) problem. This exception is not caused by the Operating System.
My experience with similar problems: the linker generates a project with the units wrongly arranged.
Example: a form unit is linked in before the base units. Forcing the project to completely recompile/relink itself should make this exception go away.
A simple [Rebuild All] will probably not suffice. You might try to recompile without optimizations.
I have tried to reproduce this error but I have not been able to. The Delphi compiler/linker is one of the best - speed of compilation/speed of compiled exes - but this bug is definitely a show stopper.
Note: I have only experienced
this error in D5. Has anybody else
experienced this error with other
Delphi versions?
I had the same problem. Class TCheckBox not found. I usually edit large set of components through .DFM of form(for example renaming large amount of component). This error comes when I rename all CheckBox on my form through it .DFM.
I just cut all the checkbox and paste them again(So .DFM file is refreshed). The error disappeared.
I've seen a similar problem due to a file copy error. To make matters more confusing, the fault was on an intermediate media device. The issue was resolved by simply recopying the file from the existing release build.
It is probably impossible to confirm now, but it is quite possible that the problem was 'solved'; not because of the removal of an unnecessay uses clause item, but because it also involved a new copy of the executable.
The solution for all errors of this type "Class XXX not found" is simple. Open DFM file of a form in text editor and manualy remove the definition of the XXX object in it.
Change the name of the Form and save the .pas with other name. Change all references to create the new unit name if this is used in other units. Build All.
With this the error disappeared.