I am upgrading an old legacy Delphi 5 application to Delphi XE7. This application is based on numerous legacy packages, one of which is DCPcrypt 1.3. DCPcrypt is problematic: it is mysteriously uninstalled between runs of the Delphi XE7 IDE, and I can't reinstall without manually cleaning the Registry. The error message given on restarting the Delphi XE7 IDE is "Can't load package DCP_d5.bpl. The specified module can't be found. Do you want to attempt to load this package the next time a project is loaded?", followed by "Package \DCP_d5.bpl can't be installed because another package with the same base name is already loaded (DCP_d5.bpl)" if I try and reinstall it.
The version of DCPcrypt in question is bundled with a description dated March 23, 1999.
Has the Delphi package system changed, leaving DCPcrypt behind and causing these errors? If so, can anyone suggest what needs to be updated?
Apparently all the packages that rely on a given package have to be uninstalled first, after which the package in question is uninstalled, rebuilt and reinstalled, and then the dependent package is rebuilt and reinstalled. Sometimes Delphi must be closed between uninstall and reinstall.
Regarding package names, the Delphi convention is not to include the Delphi version in the package name, but rather to add the Delphi version (in this case 210 for Delphi XE7) to the LIBSUFFIX in the configuration. The BPL will have the Delphi version in its name, but referencing modules can specify just the package name, and the correct BPL will be matched at build time.
In this case, I created a new XE7 package project, named it DPCcrypt, and set the LIBSUFFIX of '210' to denote Delphi XE7. I also added a DCPcrypt.rc resource file to the project with an icon named DCPCRYPT to give the package an icon. Finally, I added a conditional compilation block for VER280 in DCPcrypt.pas to set the DWORD type definition to longword, as the default was longint (a legacy of very old versions of Delphi that didn't have a 32-bit unsigned integer), and that eliminated the hundreds of signed-versus-unsigned warning messages on compilation.
The DCPcrypt project can now be loaded and installed. (Its package name is DCPcrypt but its BPL name is DCPcrypt210.) Whatever issue was hanging its load is now gone.
Related
I'm using Delphi XE5 and many years I'm using VirtualTreeView components. Now Delphi XE cannot load them. This messages appears:
The procedure entry point could not be located in the dynamic link library C:\Users\Public\Documents\RAD Studio\12.0\Bpl\VirtualTreesD19.bpl
and
Can't load package C:\Users\Public\Documents\RAD Studio\12.0\Bpl\VirtualTreesD19.bpl. The specific procedure could not be found.
I uninstall VirtualTreeView from Delphi and tried new instalation, but this not worked. Now I'm without VirtualTreeView.
I did no changes in Delphi settings and no install of anything, etc.
This situation appears after Windows 10 updates, but I don't know if it's causes my problem.
Can someone help me with this situation? Thanks.
I think I found out solutions of my problem: The packages VirtualTrees*.bpl are build into standard folder for packages, eg. C:\Users\Public\Documents\RAD Studio\12.0\Bpl or C:\Users\Public\Documents\Embarcadero\Studio\22.0\Bpl. This folders are in system variable "Path" too. The paths of newest version od Delphi are before paths of older version.
I used the same version of VirtualTree, of course in separete folders by version of Delphi, name of built packages are the same and they are in separate folders (see above). But if I check loaded packages, I found that Delphi XE5 had loaded package from path of Delphi 11. Because older version of Delphi cannot works with packages that are built in newer version, I got my excepsion. I don't why Delphi works with packages by this methode, but when I set other path for built package, e.g. .\..\build, then everythink work correctly.
I'm using Delphi Tokyo and I would like to build my App.exe with some run-time packages, so I have setup my project's options as shown below
I manually typed into the run-time packages list as shown below
While building the project I got error message that those rtl250, vcl250 could not be found
When trying to add those packages using browse button, Delphi asked me to find those packages using .dcp extention not .bpl, which I have no ideas where to find those files
Please guide me how to fix this
The names you must specify there are the names of the .dcp files. These do not contain the version numbers. Use:
rtl, vcl
...rather than:
rtl250, vcl250
...and it will work.
This is actually a feature (introduced many years ago), so you don't have to change those names when you upgrade to a new Delphi version.
First of all I would like to apologize for the question itself. I simply could not make anything better. Well, the question then follows with examples and detailed ...
I manually installed QuickReport Delphi 2006 from their sources. It is composed of two packages a "DesignTime" and a "RunTime".
My Delphi is configured to build the BPL files in "D:\BPL" and DCP files on "D:\DCP" for all packages compiled on my Delphi
The source code of QuickReport are in "D:\QuickReport" and their packages (design and runtime) are configured to save the compiled units (DCU) in the folder "D:\QuickReport\DCU." This was the only configuration done in the packages. Nothing is set up with different paths and, BPL and DCP files are placed correctly in the folders I've set up, as I mentioned earlier.
With these settings I was able to build and install QuickReport without problems (just a few compiler warnings, which I believe are normal). All QuickReport components appear in your palette in Delphi, which does not emit any error on start proving that the components are properly installed and all packages were found.
Now comes the test: I started a new win32 application, completely empty, just a blank form. Then it put a QuickReport component (TQuickRep). The first thing I noticed was that the unit "QuickRpt", which is automatically placed in the clause "uses" of the "interface" is underlined in red indicating that something is wrong.
When I perform a CTRL+ENTER in "QuickRpt" unit (uses clause), the Delphi finds the source file (.pas) correctly, which is in "D:\QuickReport" then I ran a BUILD ALL command and the following compilation error appeared:
[Pascal Fatal Error] Unit1.pas (7): F2051 Unit QuickRpt was compiled with a different version of QRExpr.TQREvElement
That's it!!!
This error is only happening with Quick Report. I have other third-party components installed using the same configuration as the paths and they all work properly.
Finally I was able to solve this problem. #RRUZ and another friend gave me the tip: An lost QuickRpt.dcu file on my system. There were a QuickRpt.res file also. I found them, but the place was very improbable to me: The delphi LIB folder!!!
Well, i have some clues about this bizarre thing.
Until Delphi 7, the QuickReport was shipped together with the IDE however, it was disabled by default. On that Delphi version, all we need to do is to register the bpl to gain full access to QuickReport!
On Delphi 2006, the QuickReport is not part of IDE and there are no BPL to register, however the guys at Borland forgotten to remove all files from the old QuickReport. The Delphi Lib Folder is one of the first folders to be checked on Delphi start, so, if there are old files there, new files on another place would be never compiled, generating the annoying error!
This problem may be present on Delphi 2005 too.
This question already has an answer here:
Step by step upgrade of Indy 10 in Delphi 2009
(1 answer)
Closed 3 years ago.
Is there a step-by-step guide for updating the Indy 10 components in Delphi 2009?
I've read the uninstalling thread and have the latest build (IndyTiburon.zip). However there appears to be no installation instructions.
If you have accomplished this, please share the details.
Edit: I have managed to get the packages installed by messing with the "requires" section in dclIndyProtocols120 and dclIndyCore120.
Essentially removed all Indy package dependencies from "requires" section and just used the Library path resolve things. Added ..\Lib\Core, ..\Lib\System and ..\Lib\Protocols to the Lib path. Had to leave dclIndyProtocols120 in requires for dclIndyCore120 as it wont install without this.
All 3 packages compiled (including IndySystem120) and seems to be working okay now.
This should be easier for D2009 users. I had to update to resolve an SMTP bug in Indy (see link).
On this question there is a more satisfying answer.
For all versions before D2009 you can use a Fulldx.bat script to recompile the packages and then just open the BPL files in (for example Indy-10.5.5\D6\dclIndyCore60.bpl and Indy-10.5.5\D6\dclIndyProtocols60.bpl) in the Delphi 2009 IDE packages dialog. Now with Delphi 2009, the FullD12.bat is there but it is not doing anything.
My simple solution is to create Indy components at run time only. I add the Indy Tiburon Core, System and Protocols to the projects search path, and also use Apache Ant with a build script to run the compiler for the final build.
One IIRC needs to compile system core and protocols in that order.
Moreover a package is a .BPL and a .DCP. So you probably would have to copy the .bpl and the .dcp to that directory in a normal case. The .BPL is what programs need to run, but to compile something that uses the .BPL (statically) you also needs the .dcp.
But that doesn't work for the Indy caseafaik because it also needs includefiles, so you need to add all their paths to the library path.
IIRC is that Delphi (at least the versions that I know) don't add directories to paths when installed, and one must always add paths to directories with .dcp or .dcu's manually.
(contrary to Lazarus that builds a list of dirs from the installed packages. But partially that is maybe also a fix for not having something akin .dcp yet, and in generally be more source oriented)
Note that I don't have D2009, it is just experience from general manual Indy compilation.
Maybe a simple method for anyone looking 10 years later... (tested under Delphi XE5):
Download the latest Version from https://indy.fulgan.com/ZIP/.
Extract the ZIP-archive into a folder of your choosing (I made a folder "Delphi Lib" under my Documents).
Throw out all Indy .dcu Files (Indy[...].dcu and Id[...].dcu) from your Delphi installation (for Example: C:\Program Files (x86)\Embarcadero\RAD Studio\12.0 (The last folders name may vary on your installation))
Open Delphi and go to Tools -> Options. Get to the "Library"-Listing and add the following folders of your newly downloaded Indy: /lib/Core/, /lib/System, /lib/Protocols.
As always: Help yourself and make backups before deleting anything. You do not want to reinstall your comlete Delphi because you threw away a file you should've kept...
Since Indy is now built-into the install process of Delphi 2009... is there a proper way to 'remove' it so it can be upgraded to the latest from the SVN repo? There isn't an automated option to remove it as far as I'm aware.
The dcu files for Indy are stored separately from the other Delphi units. To stop using them, simply remove that directory from the search path, library path, etc., and remove the source files from the browse path.
You can remove the design-time packages the same as any other design-time packages. Remove them from the IDE configuration, and then delete the bpl and dcp files. (If you just delete the files, you may get errors when you next start the IDE since it won't find the expected files.)
Once the Indy components no longer appear on the Tool Palette, the packages no longer appear on the package list, and compiling a project that references Indy units fails with a "can't find used unit" error, you're ready to start installing the latest version.
As Rob already said: Just remove the direcories from Delphi's configuration. An additional step is required though: After each update, make sure they have not been added again! Some of the Delphi 2007 updates apparently did that and I missed it for quite a while until I stumbled upon a bug that I already thought fixed.
I didn't use Delphi 2009, but in older versions of Delphi the installation of Indy components was optional. So you could try launching the setup for Delphi 2009 and see if there is an option to "Add/Remove features" or something similar and use it to remove Indy.
Also, you can customize which packages should be loaded in a project, so you can simply deselect the Indy 10 one and add the one from SVN on a per-project basis (you can also configure the default configuration for projects).
PS. Indy rocks! :-)