In Delphi XE2, I have a single control in a pair of design/run time packages. Originally, everything was working fine. I've built each of them many times already. Suddenly without warning, the design time package started complaining in one of my units that the Graphics unit is missing when I build. Graphics is a standard unit, but it's not found from this one place. I haven't even made any changes to this unit, and as far as I know, any changes that could affect this.
Here's just the uses at the top (interface) of this unit:
uses
Graphics, ColorConv, Classes, Dialogs, ZLib;
As you can see, it's a very simple unit, and I only make very simple changes to this project. What could make it start complaining about this out of nowhere?
The strange thing is that it all works fine if I install it, it just doesn't build.
There's quite a bit of code, and I'd hate to have to post the entire thing.
Wild guess: it needs the Vcl. namespace prefix?
if there are several declaration of graphics(or other VCL units like:controls,forms ...)in your project, you can add VCL namespace to your project
as follows:
project menu-->options-->delphi compiler->>add in "unit scope names" value "Vcl"
Check your paths in Tools->Options->Environment Options->Delphi Options->Library, in particular the Library Path and Browsing Path settings. The defaults for my installation of XE2 (excluding those added by third-party components and my own stuff):
Library:
c:\program files (x86)\embarcadero\rad studio\9.0\lib\Win32\release;c:\program files (x86)\embarcadero\rad studio\9.0\Imports;C:\Users\Public\Documents\RAD Studio\9.0\Dcp;c:\program files (x86)\embarcadero\rad studio\9.0\include;
Browsing:
$(BDS)\SOURCE\VCL;$(BDS)\source\rtl\common;$(BDS)\SOURCE\RTL\SYS;$(BDS)\source\rtl\win;$(BDS)\source\ToolsAPI;$(BDS)\SOURCE\IBX;$(BDS)\source\Internet;$(BDS)\SOURCE\PROPERTY EDITORS;$(BDS)\source\soap;$(BDS)\SOURCE\XML;$(BDS)\source\db;$(BDS)\source\Indy10\Core;$(BDS)\source\Indy10\System;$(BDS)\source\Indy10\Protocols;$(BDS)\source\fmx;$(BDS)\source\databinding\components;$(BDS)\source\databinding\engine;$(BDS)\source\databinding\graph;$(BDS)\source\fmi;$(BDS)\source\data;$(BDS)\source\data\ado;$(BDS)\source\data\bde;$(BDS)\source\data\cloud;$(BDS)\source\data\datasnap;$(BDS)\source\data\dbx;$(BDS)\source\data\dsnap;$(BDS)\source\data\Test;$(BDS)\source\data\vclctrls;
Also, since you're new to XE2, you may want to check to see (outside the IDE) if you have an environmental variable for PLATFORM defined. Some PC manufacturers (HP as a particular example) define this variable on their computers, and it interferes with the IDE's requirements. (The IDE uses PLATFORM as a temporary environmental variable in paths used for different platforms, which fails if there's one predefined outside the IDE.) You can check by opening a command prompt and typing SET PLATFORM and hitting Enter. If there's one pre-defined, it can cause various hard to track down problems; you can remove it safely on every machine I've run across. (Right-click My Computer or Start->Computer, choose Properties, Advanced System Settings, Environmental Variables.)
Related
When I open my project and I double click on a specific pas file in the Project Manager, bds.exe freezes and continues using 25% of the cpu. I have to kill the process through the Windows Task Manager. (1)
When I open my project and I press F12 on that exact same file, I see what I would have expected to see earlier, the contents of the pas file.
When I open my project and I compile it first, then double click on the file, everything is fine.
I'm trying to figure out how, what I assume to be a mismatched DCU file, snuck into my project and what the best way is to prevent a similar issue in the future. Can I force all DCU files to be rebuilt? Can I simply delete all dcu files and recompile or is that a dangerous thing to do? My DCU files are currently also stored in the same directory where I keep the pas and dfm files, that is a bit messy.
(1) our application also shows behaviour in production where it sometimes crashes while it continues to use a steady cpu usage or simply continues to work as expected but shows a steady cpu usage in the background. We have been unable to trigger it in a compiled version but see it popping up from time to time. We assume the dcu mismatch is at the source of this problem.
There are numerous issues in your question, some entirely unrelated, but the assumption that the problem is a "mismatched" DCU is unlikely to be correct (by which I presume you mean an "old" or otherwise incorrect DCU compiled in the past or with different source).
First your problems.
IDE Behaviour
The problem with the IDE locking up when double-clicking a unit in the Project Manager is unlikely to be anything to do with a "mismatched" DCU.
Do you have source files located on a network drive ? Is this unit such a file ? Is that network location available/valid ? i.e. is the path to the file using a network drive letter that is no longer mapped or otherwise not available ?
If there is no explicit path in the unit reference in the DPR, do you have network locations listed in your system, IDE or project PATH ?
Difficulty accessing file locations is the most likely explanation for the IDE appearing to lock up when trying to simply open a file.
As to why it should behave differently when using F12 rather than the Project Manager, unfortunately the Delphi IDE is notorious for using different mechanisms to achieve the same thing in different places so it isn't surprising that sometimes when one of these mechanisms breaks the others still work (and can give different results even when both work).
Runtime Behaviour of your App
If we work on the basis that you do indeed have a "mismatched" DCU then performing a full build of your project will resolve that mismatch, as long as you have the source for all the required DCU's and that the correct and appropriate source for each DCU is available.
However, even though the mismatch may be resolved, rebuilding may or may not fix the issue, depending on whether that issue remains in the source code for that unit itself when recompiled.
The simple fact of the DCU being "mismatched" cannot cause aberrant application behaviour. With the exception of OS or RTL bugs etc, if there are errors in the behaviour of an application then those errors will be the result of errors in the source code as compiled.
Simply recompiling source code containing an error will not remove that error.
As such, if there is such an error then far more information will be needed if anyone is to be able to give any assistance on that score (and this should be a separate question, once you have done some initial debugging and diagnostics yourself).
Runtime Packages
If you are using runtime packages then things get more complicated because with a runtime package, the DCU employed for any particular unit could be part of a package file. In that case, the DCU file on disk is produced when you compile the package itself but any project that uses that package will not use the DCU on disk but will instead use the version that has been compiled into the package.
So if you are using runtime packages then as well as rebuilding your project you need to also rebuild any and all runtime packages that may have changed.
Now, for your actual questions.
Q1: Can I Rebuild all The DCU's ?
Yes, of course. But see above w.r.t Runtime Packages, if your project uses them.
I would strongly recommend that you change your project settings to output DCU files to a specific location, separate from the source files.
For example, you could have a project specific DCU folder using a relative path. i.e. set your DCU output folder to something like ".\dcu" and create a dcu folder within the folder where your DPR is located.
For Delphi versions supporting multiple platforms and configurations it is best to include the environment variables for the platform and configuration in that path, so that you don't end up using units compiled for DEBUG in a RELEASE build.
e.g.
.\dcu\$(Platform)\$(Config)
or
.\$(Platform)\$(Config)\dcu
What Is Compiled in a Build ?
When you do a Build on a project (as distinct from a "Compile"), all units referenced by that project will be recompiled, with the exception of any VCL/RTL units (i.e. those provided with Delphi). Those get special treatment.
At a minimum, rebuilding a project will forcibly recompile all units explicitly listed in the DPR, but will also recompile all other units that are used by those units (or units that they use etc etc).
NOTE: DCU's With Missing Source
A unit will only be recompiled if the source can be located.
If you have a DCU and the source file is missing or cannot be located on the project, IDE or system path, then the compiler will simply assume that you want to use the existing DCU.
This is the case even with a full "Build".
3rd Party DCU's
It may seem obvious but you should also be careful that you don't delete DCU's that may be your only copy of any 3rd party libraries you may be using for which you do not have the source.
This is highly inadvisable, but I guess we mustn't rule out the possibility that you may be in this situation.
Q2: Should I Delete all the DCU's ?
In general, yes. As noted above, even a full build will be successful if you are missing the source code for a unit that is referenced, as long as there is a DCU (or required package, if using runtime packages) that can be found.
So the only way to be sure that you have the current source for all DCU's is to first delete the DCU's that any previous builds may have used.
This is of course much easier when you have a specific, explicit location in which all your project DCU's are output.
It's slightly more involved if you are using Runtime Packages, though if you are organising your DCU's sensibly then the only real complication is that you need to repeat the same exercise for all the projects involved, working through starting each of the runtime packages that are used and finishing with the projects that in turn use them.
Yes, you can rebuild all DCU files in your project;
In the project group window, right click on the project and select Build.
It is OK to delete all DCUs in your project, but not necessary (or desirable in case you make a mistake...).
Note that this only builds DCUs explicitly in you project (as shown in your project tree) not any implicit ones imported as a result of your uses clauses.
Three things may be going on that have not been adressed in other answers.
Note that I only have experience with Delphi XE2 and Seattle 10, but they may apply to your version.
Delphi can be slow when switching from form to source view, especially if you have many components on your form. In migrating from XE2 to 10, we noticed an improvement here. We are talking seconds here, this does not seem to be your issue.
Delphi can be notoriously slow when switching between projects. After a switch the IDE can take a very long time (20-30 seconds) to respond. You cannot type anything; code completion takes a long time; initiating a project search with Alt-S-D waits a long time, then fails. In migrating from XE2 to 10, we noticed a large deterioration here.
Conditional compilation. If you have IFDEFs in your code compiling stuff for one project but not for another, your IDE can hang completely, and there's nothing else you can do then killing BDS.EXE. This happens in Delphi Seattle 10 if you switch projects and accidentally Compile instead of Build.
You may experience variations of these.
I have this craving to do some experiments with modifying the underbelly of the Delphi run time library (RTL), system.pas and the likes... It is possible or not?
I'm very fond of challenges like "yes, but you'll have to provide custom .obj files for some assembler wizardry because they were never distributed with the official Delphi source". Fine with me, I just want to know.
I want to do this experiment with Delphi 7, but inside information on any other version is fine. It is one of the perks of being with a company that worked with Delphi since the Stone Age.
(I always figured this to be one of those RTFM questions, with the answer being a resounding "NO!", but for some reason google won't confirm it.)
You can recompile the RTL like any other unit.
For System.pas you must use the command line compiler.
For instance, here is a working batch file content (there is some not well documented command line switches):
del *.dcu /s
"c:\program files\borland\delphi7\bin\dcc32.exe" -O+ -Q -M -Y -Z -$D+ System.pas
This will recompile System.pas and SysInit.pas (both lowest level RTL files).
But in order to use your recreated dcu files, you'll have to put the folder containing the updated dcu files into the first position of your IDE: for instance, in Delphi 7 it's Option / Environment Options / Library, then put your folder FIRST in both "Libary path" and "Browsing path" field.
And it's perhaps worth deleting the original .dcu files in your Delphi installation directory.
But be sure you won't change the "interface" part of the unit, or you'll have troubles with compiling with other not modified units of the RTL (or third-party components). You can change the "implementation" part, apply fixes or rewrite some part for speed or such, but don't change the "interface" part to avoid any linking error.
Always make a backup of the original .pas and .dcu files which you are changing. And it's a good idea to make some automated compilation test, so that you could be sure that your modifications of the RTL won't add any regression.
We made such a RTL recompilation for our Enhanced Run Time Library for better speed of low-level RTL functions (mostly System.pas and SysUtils.pas). Designed for Delphi 7 and 2007. For more recent Delphi version, you still can use the same principle.
You can only recompile the RTL from the command-line. There should be a makefile in the RTL source directory of your installation. It is designed to be used with the make.exe command-line utility which should be in the "bin" folder of your installation. I would recommend you copy the relevant sources to a separate location for experimentation. I must caution you that the System unit is tightly coupled with the compiler which expects many functions to have a specific name and have particular parameter lists, if any are even declared. Many RTL "helper" functions don't have any formally declared parameters, yet expect parameters to be passed in a certain fashion.
Another bit of caution is changing the interface declarations of certain classes, functions or types. Doing so may cause serious incompatibilities with existing DCU files and components. For this reason you must be very careful when intermixing DCU files from the included RTL or third-party components with your custom modified versions. I would suggest you start by only making implementation section changes only before venturing into the mine-field of interface breaking changes.
I'm migrating a Delphi 2 project to RAD Studio XE2.
When I try to compile I get
[DCC Fatal Error] MyUnit.pas(9): F2051 Unit JclUnitVersioning was compiled with a different version of System.Contnrs.TObjectList.Remove
at the following row:
unit MyUnit;
interface
uses
Windows, Messages, SysUtils, Classes, Graphics, Controls, Forms, Dialogs,
StdCtrls, DB, DBTables, TB97, ExtCtrls, Grids, DBGrids, Vcl.Mask, JvExMask,
Vcl.DBLookup,
JvToolEdit, {<-- error here}
TB97Ctls;
{...}
I tried uninstalling and reinstalling RAD Studio, JCL and JVCL, but nothing changes.
Update Was using the binary Jedi installer from A.Hausladen (intended for use in Delphi trial editions only).
You either have old DCU files lying around that need to be rebuilt, or removed, or your project or library path contents are not consistent. (Find files named JclUnitVersioning.dcu that are not in the proper JCL Library folder, and remove them. The proper library folders are named jcl\lib\d7, through jcl\lib\d16, depending on your delphi version number )
This usually means that your project has access to both a directory that is in your library-path (or project search path) that contains pre-compiled DCU files, and may also have access to some source units (.pas files), and that one or more of the units that depends on other units, was compiled at a different time than now, with multiple versions of a common unit. I wish I could draw you a picture.
Imagine you have a car, and someone upgrades the engine, changing it from a V6 to a V8. Now someone who had previously been servicing your engine comes back and tries to find the place where the V6's exhaust manifold attached. It's not there any more, it's moved. Since the new engine is frozen in its current shape (stay with me here!), your service technician simply goes back to you (the customer) and says, "sorry, I'm confused, I can't continue, I give up". That's roughly what this error message means.
Cleaning it up is possible in several ways; It may be a simple matter for you to make sure you compile 100% from .pas files, and have no Library folders containing .dcu files at all. Of course, that's hardly ideal, is it, since the whole purpose of a Library path was to contain a precompiled "library" of DCU files.
So instead, I suggest you do a cleanup (delete all your DCU files) and rebuild all your component packages from source (you do have a batch file for that purpose right?) and then review both your project's search path, and library path to see that both contain only the folders you think they should contain.
Just had the same problem with Delphi 2010 and XE3 (both on same PC while migrating).
After several hours of recompiling both my projects and the JCL projects (the installer bat file errors on my PC) discovered the problem was the order in which the directories were declared in the tools/options/Delphi Options/libraries.
Took them all out, added the version specific directory (eg lib\D14, lib\D17\Win32) and then the other JCL sub-directories required (ie one at a time until a project using JCL would build)
Simple fix:
After JCL package install, reboot your PC to apply Path change. (The installer will ask for it.)
Open from Delphi IDE the JCL package. eg.: ..\jcl\packages\d7\Jcl.dpk
Click Project menu > Build ! (do not just compile)
Save all changes, close Delphi.
Now JVCL\install.bat should work fine. Tested just now with Delphi7 Light Edition 7.3.4.3
(You may also edit that .bat file and change the first line from #echo off to echo on, to see more detailed infos, what's going on.)
I'm migrating a Delphi 2 project to RAD Studio XE2.
When I try to compile I get
[DCC Fatal Error] MyUnit.pas(9): F2051 Unit JclUnitVersioning was compiled with a different version of System.Contnrs.TObjectList.Remove
at the following row:
unit MyUnit;
interface
uses
Windows, Messages, SysUtils, Classes, Graphics, Controls, Forms, Dialogs,
StdCtrls, DB, DBTables, TB97, ExtCtrls, Grids, DBGrids, Vcl.Mask, JvExMask,
Vcl.DBLookup,
JvToolEdit, {<-- error here}
TB97Ctls;
{...}
I tried uninstalling and reinstalling RAD Studio, JCL and JVCL, but nothing changes.
Update Was using the binary Jedi installer from A.Hausladen (intended for use in Delphi trial editions only).
You either have old DCU files lying around that need to be rebuilt, or removed, or your project or library path contents are not consistent. (Find files named JclUnitVersioning.dcu that are not in the proper JCL Library folder, and remove them. The proper library folders are named jcl\lib\d7, through jcl\lib\d16, depending on your delphi version number )
This usually means that your project has access to both a directory that is in your library-path (or project search path) that contains pre-compiled DCU files, and may also have access to some source units (.pas files), and that one or more of the units that depends on other units, was compiled at a different time than now, with multiple versions of a common unit. I wish I could draw you a picture.
Imagine you have a car, and someone upgrades the engine, changing it from a V6 to a V8. Now someone who had previously been servicing your engine comes back and tries to find the place where the V6's exhaust manifold attached. It's not there any more, it's moved. Since the new engine is frozen in its current shape (stay with me here!), your service technician simply goes back to you (the customer) and says, "sorry, I'm confused, I can't continue, I give up". That's roughly what this error message means.
Cleaning it up is possible in several ways; It may be a simple matter for you to make sure you compile 100% from .pas files, and have no Library folders containing .dcu files at all. Of course, that's hardly ideal, is it, since the whole purpose of a Library path was to contain a precompiled "library" of DCU files.
So instead, I suggest you do a cleanup (delete all your DCU files) and rebuild all your component packages from source (you do have a batch file for that purpose right?) and then review both your project's search path, and library path to see that both contain only the folders you think they should contain.
Just had the same problem with Delphi 2010 and XE3 (both on same PC while migrating).
After several hours of recompiling both my projects and the JCL projects (the installer bat file errors on my PC) discovered the problem was the order in which the directories were declared in the tools/options/Delphi Options/libraries.
Took them all out, added the version specific directory (eg lib\D14, lib\D17\Win32) and then the other JCL sub-directories required (ie one at a time until a project using JCL would build)
Simple fix:
After JCL package install, reboot your PC to apply Path change. (The installer will ask for it.)
Open from Delphi IDE the JCL package. eg.: ..\jcl\packages\d7\Jcl.dpk
Click Project menu > Build ! (do not just compile)
Save all changes, close Delphi.
Now JVCL\install.bat should work fine. Tested just now with Delphi7 Light Edition 7.3.4.3
(You may also edit that .bat file and change the first line from #echo off to echo on, to see more detailed infos, what's going on.)
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.