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.
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 use Delphi 10.1 Berlin Starter and have the following problem:
Is added some packages by opening them, and installing them by right-clicking on the package in the project manager and choosing "install". The compiled packages are now in the same folder as the other packages Delphi uses, so I think that there cannot be a problem with the library or search path.
The packages also added some Components that are now accessible in the tool palette. If I add one of these components to my program, Delphi automatically adds the unit name of the component to the "uses" section of the unit containing the component. But if I want to compile, Delphi throws the fatal error "could not find unit_name.pas".
How can I fix this? Does the units required to build and install the packages have to be included in a library path?
Maybe this is a compatibility problem. The packages were written in 2008 (Are Namespaces in Delphi younger?), so maybe the way the package wants to tell the compiler what to do does not work anymore.
This question might be difficult to understand (I had some problems to explain it...), so please comment, if you need more information.
Quite easy, I just had to add the units of the package to the library path (Tools->Options->Delphi Options->Library). Worked. Thanks to KenWhite.
I write a lot of components and libraries for Delphi, most of which require the use of BPL Packaging so that they may be installed into the IDE.
This is simple enough and works well, right up until you want to maintain a single set of Package Project Files (in a single Project Group), but also want to compile and distribute those same packages for different Delphi versions.
Up to now I've been creating a different Package Project for each version of Delphi, and explicitly defining a Delphi Version Identifier as a suffix (e.g. Kinect_XE.bpl and Kinect_XE2.bpl).
I am aware that, in the Project Options for a Package Project, under Description, there are the fields LIB prefix and (more importantly for my needs) LIB suffix.
I am further aware that if I place a value in LIB suffix, it'll be appended to the end of the compiled BPL's filename.
My question, however, is first whether it is possible to have the IDE automatically populate the LIB suffix field with the IDE/RTL Version number, and if so... how?
I'm fairly certain this is possible, as it would appear that vcl120.bpl (and its counterparts for each respective version of Delphi) can be Referenced (as requirements) of your own packages using just vcl rather than having to type the full vcl120. It is, in fact, this same behaviour I'm hoping to achieve... where my packages can intra-reference eachother (as neccessary) without having to provide version-specific references to accommodate the suffixes.
Equally important is that resolving this will enable me to maintain a single set of Project Files in a single Project Group (with the obvious exception of XE2 where its Project Files don't necessarily behave very well with previous versions of Delphi due to the Platforms addition).
I suspect that I may need to put a value like $(VER) (or something similar) in the LIB suffix field, but this appears not to work and I've scoured Google looking for the correct solution.
Hope you can help!
UPDATE 1
I am now writing an IDE plugin to be used with (in the very least) Delphi 2007 to XE2, which gives DLL and BPL projects a new option called AutoSuffix. When toggled On, any IDE with the AutoSuffix plugin installed will immediately apply the correct IDE version suffix to the project.
The AutoSuffix plugin will be made available (freely) for everyone within the next 24 hours, and this question updated accordingly.
UPDATE 2
Okay... Delphi 2007 is being a pain! I've made AutoSuffix work with 2009 to XE2, so far, but 2007 requires a little more time (patience appreciated).
UPDATE 3
It would appear as though Embarcadero have heard our collective cry for simplier package unification between versions.
Mark is going to push this through to see if future versions of Delphi can accommodate a {$LIBSUFFIX AUTO} feature. I hope to hear back very soon whether this will be the case. If so, it certainly affects the way AutoSuffix will need to work on XE2 and older versions (as presently it doesn't provide the simple AUTO switch.. it has its own method).
My hope now is that EMB will take this request seriously, provide it as an integral feature going forward, so that it becomes a simple case of using AutoSuffix on existing versions to unify the process accross all versions!
AFAIK for Delphi up to XE2 there is no automatism for doing this.
Concerning the requires clause: when you require another package you are actually using the dcp, which doesn't inherit the LIBSUFFIX. Thus it is sufficient to require VCL.dcp during compile time, while VCL160.bpl is actually used during runtime. The DCP includes the complete BPL name to resolve that.
This makes the LIBSUFFIX approach superior to the simple "rename the package for each version of Delphi" one.
A solution like that suggested in QC83229 would make it easier to port a package to a newer Delphi version, but then you are still stuck with dproj files that are not backwards compatible.
I normally use different folders for each Delphi version, where only the project files are stored. For a new Delphi version I only have to copy a folder and change the LIBSUFFIX.
LIBSUFFIX directive is in *.dpk file, and you can edit *.dpk file manually.
You can write, for example
{$IFDEF CONDITIONALEXPRESSIONS}
{$IF CompilerVersion = 20.0}
{$LIBSUFFIX '120'}
{$IFEND}
{$IF CompilerVersion = 21.0}
{$LIBSUFFIX '140'}
{$IFEND}
{$ENDIF}
The bad thing is that IDE does not respect your manual edits of *.dpk file and deletes them then you make changes in a package. That is why some component vendors that use conditional defines in *.dpk file say in installation instruction if asked to save changes say 'NO'.
My suggestion would be to add this as a configurable option to project option sets (see QC #86491.) Rather than updating all the packages it would be sufficient to update a single option set file.
In fact, it seems the DllSuffix tag is recognized by the option set files in Delphi XE/XE2. Adding <DllSuffix>160</DllSuffix> to the <PropertyGroup> section of an option set file will cause the suffix to be appended to the package in the project manager. However, you still have to open the project options and click OK in order for it to be saved to the .dpk file.
I agree that it would be extremely useful with this feature (I would think also for the packages in the RTL.)
{$LIBSUFFIX AUTO} feature was added in Delphi 10.4.1:
In previous versions (version 10.3 and earlier) of C++Builder and
Delphi developers building packages needed to manually set their
package’s library suffix setting. The DocWiki “What’s new in version
10.4.1” mentions a new IDE projects option for setting the library suffix:
“Package AUTO libsuffix: packages can now have an automatic version
suffix, instead of manually updating and specifying the right version
suffix with each new release. (The compiler quietly supported this in
10.4, but full support for the feature in the IDE and package project settings is introduced in 10.4.1.)”
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...