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.
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.
Can anyone throw any light on an apparent partial incompatibility between TLibImp in Delphi 7and Win7 64-bit? Or suggest a less long-winded work-around than the one below?
I realise D7 is a bit long in the tooth, btw, but otherwise its IDE seems to behave faultlessly in Win7, which I suppose is a testament to MS's efforts on backwards compatibility.
Looking into another SO question earlier, I tried to use it to import ActiveDS.Tlb from \Windows\SysWOW64 using Project | Import Type library, but got an "Error accessing the OLE registry" error. I got the same error trying the copy in System32. Trying to import ActiveDS.Dll from both places I got "Error loading type library" instead.
I tried all the things which people say in the MS communities to try (Run Delphi as Administrator, Disable UAC, etc) and which David Heffernan told me (correctly) that I needn't do when I ran into the "Error accessing the OLE registry" error when I mistakenly tried to import a type library into XE4 the wrong way.
Otoh, on Win7 64-bit, D7 imports the type library for Adobe Acrobat and many others without complaint.
I managed to work around the problem by importing the ActiveDS.Tlb using XE6 and editing out the unit namespace prefixes, fwiw.
Also, I seem to recall but can't currently find a fix for one of the supplied units (ComObj maybe) for D5/D7
to avoid getting this error when a Delphi application started up which was caused by something like a problem in the way the COM object factory was initialized. But unfortunately, unlike some of the other Delphi utilities like TRegSvr, the source for TLibImp isn't supplied
There's not much to say here. Type library importing is a recurring problem area. Sometimes old versions of Delphi will import the libraries when new versions will not. And sometimes vice versa, as you have encountered. The type library importer has bugs, that's the long and the short of it.
Your workaround is the most effective way to deal with such problems. There's no point submitting a QC report because the problem is fixed in the latest version.
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've been banging my head against this for the past two days and can't seem to make any progress...
Pretty much from one moment to the next, Delphi XE2 won't properly compile one of my projects any more. That is, it actually compiles without errors but at runtime I get resource not found errors for what is essentially the main "form" (it's actually a data module in this case). I have already reverted to older versions of the project from source control that I know were definitely working alright but to no avail. Judging by that it seems it must be something inside Delphi/the IDE itself rather than in the project source. However, I have also not been able to reproduce the issue with a simple test project nor with any other real-life projects... It only happens with this one.
Another strange thing is that when I look at the produced binary with XN Resource Explorer everything looks as it should: The form resource mentioned in the error message is actually there and intact...
At some point I was suspecting this might be caused by a bug in one of the experts I have installed in my IDE (e.g. Uwe's platform and OI experts and VersionInsightPlus, Andreas' IDEFixPack and DDevExtensions, GExperts) but even after disabling all these the problem persisted.
Unfortunately, I am unable to track down exactly when this started to happen as I had been working for some time without actually running the binary, fixing compiler warnings and errors for the x64-target, adjusting build events for updated third-party tools (localization and license protection) and such things...
Has anyone else ever seen anything like this happen? Any more ideas on how to pin this down?
Some more details about the project:
It is an addin for Outlook built using the Add-In-Express framework (i.e. a COM-DLL).
The "main form" is a TDataModule-descendant - we also inserted our own ancestor-class into the hierarchy, i.e. the "addin module" is not directly inheriting from TadxCOMAddInModule - the resources of the custom ancestor forms also appear to be present and intact in the output binary when checking with a resource viewer.
Built without runtime packages for the Win32 and Win64 platforms.
Let me know if you think I missed to mention any other potentially relevant details.
Update:
I have now transferred the sources in question onto a different machine. Interestingly, the DLL I compiled there did not exhibit the problem - on that machine that is... when I transfered it back to the original machine and I tried to call it, the error was back (to stress this: this was the exact same DLL producing a EResNotFound on one machine but not on the other. Of course, once I had discovered this, I also performed the reverse test and lo and behold, the DLL compiled on the original machine works without errors on the other machine...
Seems this might not be a Delphi problem after all... but what is it then?
Differences between the two machines:
Machine 1 (the one were the problem occurs): Windows 7 Ultimate English 64bit with Delphi XE2 Update 4
Machine 2: Windows 7 Professional German 32bit with Delphi XE2 Update 3
On a third machine that is almost identical to the first except that it doesn't have Delphi on it, DLLs produced by both machines work flawlessly.
I am a bit surprised to see your question here. :)
We faced a number of serious issues with recent Update 4 for Delphi XE2. Though we have never run into or been reported of the "resource not found" error, I think this update might be one of the causes. Have you installed it?
One more thing that comes to my mind is images that you use for your Office controls (command bar and ribbon). Probably they got broken somehow, the run-time code cannot load them and reports this error.
Anyway, as you understand, these are just my guesses, if you need our assistance with your office add-in please contact Add-in Express support service, we will try to help.
Update: Seems I was a bit too quick, drawing conclusions. Apparently the Sisulizer solution is also supposed to perform a fallback to the main resource block. I have now taken this issue to the product forum and will report back here, once this is resolved.
Alright, mystery solved at last:
I had turned off the option to "Copy all resources" in Sisulizer in an attempt to reduce the size of the produced resource DLLs and then had forgotten about it...
I hadn't fully realized the implications of the standard Delphi resource DLL approach to localization on which Sisulizer "piggybacks" - especially that it was an all-or-nothing deal: Our previous translation solution implemented a fallback-mechanism that would read any resources not found in the external resource DLL from the host binary instead. This does not appear to be the case with Sisulizer - at least not out of the box... thus, any resource that's not contained in the localized resource DLL does not exist as far as the application is concerned.
I also didn't realize that the mere existence of a file with the same base name as the main binary and an extension matching the current system's default locale (such as .EN or .DE) would automatically cause the VCL to load it...
The machines that did not exhibit the error either still had the older, larger (=complete) resource DLLs on them, or no resource DLLs at all.
We are trying to split up our monolithic EXE into a combination of an EXE and several packages. So far, we have one package that we're trying to use, and when running the EXE Codeguard shows the following error on startup:
CG Error
Two different CRTLDLLs are loaded. CG might report false errors
(C:\Windows\system32\CC32100MT.DLL)
(D:\Projects\Foo\Bar.bpl)
OK
I read this as two different runtime libraries being loaded - one, the correct one (CC32100MT.dll), one incorrect, which is the package we're trying to use.
Continuing to run the program shows odd errors, especially casting between classes or passing a pointer to a class as a parameter in a method that crosses the EXE/DLL boundary. Codeguard itself doesn't show any other errors at all though. Edit: This is now resolved, and wasn't related. The program appears to run correctly, but the warning Codeguard shows is still worrying.
How do we solve this?
Some more details
We've looked at as many things as we (the developer working on this and I) can collectively think of:
Each project is built using runtime packages. The EXE host lists Bar in its package list.
Each project is set to compile with dynamic RTL. However, changing this does not solve the problem.
The package is linked to the EXE via its BPI file, but linking via a LIB makes no difference either.
The EXE and BPL are compiled with the same project settings, where the same options exist for both types of project. We think, anyway :)
There is only one copy of the BPL and BPI on the system: it's definitely linking to the right one.
Examining the EXE and BPL with Depends and TDump show they are both using C:\Windows\system32\CC32100MT.DLL. They should both be using the one RTL.
Creating a new project (a plain VCL forms application) and linking to the BPL (via its BPI) works fine. Something in the process of adding all the files and LIBs that make our EXE contain the code it needs to changes this, but we haven't been able to figure out what.
The LIBs all either correspond to DLLs we use (flat C interface, usually look as though they were built with MSVC) or are simple projects with lots of related files, compiled to a lib for the purpose of linking into the EXE - these correspond roughly to the areas of the program we want to split to BPLs, by the way. There don't seem to be project options for the LIB projects that would affect RTL linking, unless we've missed them.
I have exhaustively hunted through Depends and looked at all RTL and CC32*.dll files the EXE and every single DLL references. All are identical: rtl140.bpl and CC32100MT.DLL. Fully qualified paths show they are the same files, too. Everything should be using the one same run-time library.
Edit: The final EXE is complex, built with several libs, several DLLs, etc. All these, when built with C++Builder, are built with the current version. Is it possible there's something in one of these DLLs or LIBs that could cause a problem? I don't know enough about how the RTL is linked in to be sure about where to look... my (naive?) assumption is that the linker would normally link in one set of RTL functions, but that of course doesn't seem to be happening... and I don't know how things change when using packages. Is it possible this error has always existed and Codeguard has not flagged it before, because we haven't used something dynamic like a package?
Perhaps another question is, Why would a package have its own RTL anyway, or what would make it count as 'a RTL DLL' to Codeguard?
We're stumped. Absolutely stumped. We've had other problems using BPLs (they seem to be surprisingly tricky things, especially using C++) but have managed to solve them all. This one we've had no luck at all and we'd really appreciate any insights :)
We're using C++Builder 2010 (as part of RAD Studio actually, but with little Delphi code apart from components.)
Edit: Started a bounty. I'd really like to solve this!
Edit 2: Thanks to David Dean for his help (marked as answered below.) Via email, he pointed out this issue was reproduced in a simple test case by someone else, and is logged in Embarcadero QC as report 86335. Currently there is no fix, but the warning does not appear to indicate a genuine problem (ie, it's probably a spurious error, and while it's a pity to have to click past the dialog when you run, hopefully there's nothing in the error to worry about.)
Since one of these is coming from a .bpl, did you try turning off "Build with runtime packages" in the project options?
We had a similar problem. We tracked it down to a (non VCL) .cbproj that was created without the "Multithreaded" option.
As far as I can tell, the only time you get chance to set this option is when you create a new .cbproj, it cannot be changed afterwards using the GUI. We ended up "hacking" the .cbproj to include the following:
<Multithreaded>true</Multithreaded>
To determine which dll is causing the issue, it should be the last dll loaded in the output window just before you see the CG message.
Did you check if you use _TCHAR as char. We had some similar problems with RAD Studio and we found a workaround using _TCHAR as char. As soon as one DLL or BPL Project is compiled with wchar_t, this code guard error appears.
We also figured out, that EXE projects can be compiled with TCHAR = wchar_t without any problem (the main function will be WIDE).
The settings does not affect the GUI being able to handle UNICODE.
A customer logged a similar case in our public bug tracking system and the bug has been identified and fixed in the latest release.