I have lots of components that worked perfectly under D7.
I managed to compile and install them by dragging them into the Delphi 2009 IDE.
However, when I try to use those components in a project, the compiler says it cannot find the source code of them.
Where I can enter the path to that library?
Solution:
I dragged and dropped the old DPK file in Delphi 2009. Then in project manager I choose “Build” an then “Install”.
Everything worked smoothly except that the applications that used the controls couldn't see its source.
Problem solved by adding the path into the Tool-Options-Library Win32.
Thanks to everybody and especially to Mohammed.
Have you added the source path of the components to your library path?
you can add it from Tools menu > Options > Library win 32 >Library path
If you've really installed them, then the compiler shouldn't need to find the source code. The compiler only needs the DCU files.
But if you've taken these components from Delphi 7, then you need to have the source code, because Delphi 7 DCU files are not compatible with Delphi 2009. (The only two versions ever that can use each other's DCU files are Delphi 2006 and Delphi 2007, and then only with certain restrictions.)
Trying to use DCU files from the wrong Delphi version will cause Delphi to try to recompile the units. The solution is not just to provide the path to the source code, though. If the units files haven't been compiled yet (and they obviously haven't if they're of the wrong Delphi version), then you haven't really installed anything. Installing components in Delphi has never involved dragging and dropping. Installing a component means installing the package that contains that component, and installing a package often means opening the DPK project file and then choosing the "install" command in the IDE.
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 have a large project group I'm in the process of updating from C++ Builder 2010 to Seattle. So quite a jump :) I have run into several issues and managed to solve them all but yesterday I scratched my head a bit. One project builds a bpl used by other parts of the system. After some minor code tweaks it compiles fine but when I right-click the project to "install" the bpl I get an error message saying
The procedure entry point
#TLanguageDialog#$bctr$qqrp25System#Classes#TComponent could not be
located in the dynamic link library TranslationTools.bpl
TComponent is part of the VCL library if I remember correctly so I'm trying to figure out what the issue here is and how to solve it. Has something in the way bpl's are constructed changed so it's expecting something that didn't use to be there or what? As said it compiles just fine, but just in case here are the settings for the include and lib paths.
Include: $(BDSINCLUDE)\windows\vcl;$(BDSINCLUDE)\windows\vcl\design
Lib: $(BDSLIB)\$(PLATFORM)\$(Config);$(BDSLIB)\$(PLATFORM)\Release\psdk
The solution ended up being rouge bpl files like Remy sugested. bpl files had ended up in System32. Although all installed bpl files had been uninstalled in the IDE a version of the build project was once installed to the system and wrote bpl files to System32 which caused the IDE to try and use these and not my newly compiled ones.
I have encountered a problem in which setting AutoRefresh to True in TShellListView leads to memory leaks. This is a known problem, I found a fix for it here: http://www.delphigroups.info/2/bf/292629.html.
My problem is that my application is currently compiled with Delphi 2010 (Rad Studio 7), and that version does not include source for ShellCtrls.pas, which must be modified to implement the fix described above.
I also have a copy of Rad Studio 9 (Delphi XE) on my development machine. This version does include a copy of ShellCtrls.pas. Hoping against hope, is it possible to use the source from XE in 2010? If not, is there any way to get a hold of the of the source for ShellCtrls for Delphi 2010?
Source code is included for all Professional and higher SKUs (although the VCL source included varies based on SKU, the demos usually don't because they want you to want the functionality and therefore upgrade your SKU). If you don't have the source in D2010, you're either looking in the wrong place (it's in the Samples or Demo folder, not the VCL source folder) or you've not installed the demos.
The demos are installed by default in the Users\Public\Documents\ tree; you can find them using the Start Menu for the version of Delphi/RAD Studio you're using.
For example, for Delphi 2007 they're located in C:\Users\Public\Documents\RAD Studio\5.0\Demos on Win7, and the ShellControls folder is specifically in C:\Users\Public\Documents\RAD Studio\5.0\Demos\DelphiWin32\VCLWin32\ShellControls.
In XE2, that changes very little; they're in C:\Users\Public\Documents\RAD Studio\9.0\Samples\Delphi\VCL\ShellControls.
(Just as an FYI thing: On Delphi 7 under WinXP, they're in C:\Program Files\Borland\Delphi7\Demos\ShellControls, so the ShellControls stuff has been around at least that long with source.)
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.
After installing Delphi XE, my good-old Delphi 7 started to crash more often. Today, I have discovered that one of my BPLs was still loaded by D7 even if I deleted it from "c:\Program Files\Borland\Delphi7\Projects\Bpl".
After I have searched the entire disk I have discovered a copy of that BPL in "c:\Users\Public\Documents\RAD Studio\8.0\Bpl".
My question is: why is Delphi 7 looking in "c:\Users\Public\Documents\RAD Studio\8.0\Bpl"?
How can I convince it to look only in "c:\Program Files\Borland\Delphi7\Projects\Bpl" ?
Delphi XE probably augments the PATH environment variable to include the Delphi XE Bpl folder. Delphi 7 doesn't know any better; it calls LoadLibrary just like everything else, and that searches the system path.
Follow the Delphi example and give your packages version-specific suffixes reflecting what version of Delphi they're for. You should be able to configure that in the project options, or else you can just have version-specific project files that already have the version suffixes in their names. That way, even if the Delphi XE version of the package is visible on the path, it won't have the right name, so Delphi 7 won't try to load it.