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.
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.
Using the latest Indy10 sources from subversion, installing in to Delphi XE4,
I get this error when I try to install "dclIndyProtocols180.bpl":
Error:
Can't load package C:\dev\..\comp\Indy10\Lib\Output\BPI\Win32\Debug\dclIndyProtocols180.bpl.
%1 is not a valid Win32 application.
The BPI\Win32\Debug folder in question contains these files:
dclIndyCore180.bpl
dclIndyProtocols180.bpl
IndyCore180.bpi
IndyCore180.bpl
IndyProtocols180.bpi
IndyProtocols180.bpl
IndySystem180.bpi
IndySystem180.bpl
How do I fix or work around this? I am not exactly new to Indy, or Delphi, but each time there's a new delphi release, there are interesting surprises for those of us who prefer to build from source code and track subversion rather than using that random point in time which ships with the Delphi XE4 installer.
As a general side question: Is there any place where the status of the Indy project's subversion code, compared with whatever Embarcadero ships in their products is noted, or recorded?
By default a new package in Delphi might automatically be 64 bit, or you may have built a dependency as a 64 bit BPL, but not have switched to 32 bit for that BPL and rebuilt it.
Also you might have folders in your Library path that allow 32 bit and 64 bit BPls to try to load each other, causing this issue.
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 have never written a property editor from scratch, but had some help with one in another question. Refer to the accepted answer there. This was in Delphi 7, and now I have started using XE2 and I have to make sure my property editor is compatible with both 7 and XE2.
It's essentially a collection editor, with the difference that each collection item has its own named component in the parent form. Is there anything new about the property editors in XE2 since 7, since it is a huge version jump?
I do NOT want to make a complete copy of my unit for different versions. I want to maintain all possible versions in one unit.
Edit
It appears that Delphi XE2 has the same property editors as Delphi 7, but the issue I was facing was that although I was including DesignIDE in my package, it could not find anything, so I had to add the ToolsAPI folder to my library path.
However, now I have a new issue after this.
[DCC Fatal Error] ToolsAPI.pas(18): F1026 File not found: 'DockForm.dcu'
I'm lost in the whole concept of BPL packages and requiring others, etc.
DesignIntf, DesignEditors, DesignMenus, DesignWindows are part of DesignIDE.bpl and is found in \Embarcadero\RAD_Studio\9.0\lib\win32\release\designide.dcp. But there is no designide.dcp for 64bit which is why it throws an error when compiling a 64bit package that references these units.
There is no 64bit version of DesignIDE because it is for a design time package and design time packages are 32 bit only (remember Delphi IDE is still only 32 bits). So always set your design time package as 32bit, not 64bit. :)
Mike
The DockForm.pas source code is available neither in Delphi XE nor in Delphi XE2.
You may try this accepted answer posted on SO applying to similar issue on Delphi 2010.
Presumably, it is compiled and included within some package already distributed with Delphi XE2.
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.