I programmed a custom-component and tried to install it in my Delphi 10.1 environment.
I only had a .Pas-file.
I went to:
Components - Install-Components, selected my Unit which is in a new folder on my desktop -> made a new package in the same directory -> hit finish
now when I open my packege in the IDE and set the platform to windows 64Bit I can compile but not install my component.
my component is derived from the TEdit-control, don't know if this is relevant.
in my requires list are the following:
dbrtl.dcp
rtl.dcp
vcl.dcp
vclactnband.dcp
vcldb.dcp
vclx.dcp
xmlrtl.dcp
I'd really like to use my component in 32Bit-applications as well as 64Bit applications.
Other VCL-Controls provided by the IDE have no problem compiling in a 64Bit application, but my component is greyed out when I set my project to 64Bit.
I'm on win8.1 64Bit.
The IDE is a 32 bit process. Therefore you can only install 32 bit packages. However, the runtime, 64 bit programs can use your component. Either by linking it directly, or by runtime packages. In the latter case, you would need to supply a 64 bit runtime package.
This is covered in some detail by the documentation: http://docwiki.embarcadero.com/RADStudio/en/64-bit_Windows_Application_Development#Considerations_for_64-bit_Applications
Related
RAD Studio 10.4.2 C++Builder running on Windows 10 Pro 64-bit PC. Target VCL Win64 (ie Clang64 compiler).
I have a large C++ project that is under development using VCL Clang64. I am compiling using static linking of all RTL libraries and all installed component packages.
It was compiling and running OK before. I've added some new stuff, and now it compiles and links without reporting any errors, but when I run it I get an error box and the application doesn't run (doesn't even start up). The error box says.
Error reading OKBitBtn.Kind: Resource BBOK not found
I have used Notepad++ "find in files" to search all directories for a file containing BBOK, but it says "none found".
If I compile with the "Use runtime packages" project option enabled, I get an AV when I try to run the EXE file.
If I compile and link using Clang32 (target = Win32) with static linking, it runs ok - no sign of any errors (but I need a 64-bit application to interface to my PostgreSQL database using FireDAC, so this experiment won't talk to the database, as expected).
I am at a loss as to what can cause this error, and what debugging steps I should take to track it down and solve it.
(thanks to Remy for making edit improvements to my mquestion)
Thanks to help from David Millington and Miguel Moreno (provided by skype conversation I now have the solution:
I have some of my own VCL components that are written in C++ (and work with the classic compiler). I had these de-selected in the "installed packages" list - but they were still listed (with empty check boxes). I know that RAD studio 10.4.2 (and earlier) does not work well with VCL components written in C++ and compiled with clang32 or clang64 compilers.
If I "remove" these components from the list then the problem is solved. At this point I have no idea why this happens.
This is a bit of a pain as it means swapping from projects that use the components with classic compiler (many) to the big project I am spending a lot of time on is not convenient. However it is an acceptable workaround. I am hoping that this issue will be fixed in the coming RAD Studio 11 version.
I'm using the new Delphi Tokyo 10.2.2 and, in my case, I use packages loaded at runtime.
Even making a simple example and requesting EXE to load only the RTL unit occurs a run-time error, only on the Windows XP operating system:
The procedure entry point inet_ntop could not be located in the dynamic link library WS2_32.dll.
Using Delphi Tokyo 10.2.1 the problem does not happen.
Any idea?
I have a new project proxy functions to all exported functions of original Windows XP's WS2_32.dll including inet_pton that was missing in Windows XP's WS2_32.dll.
It tricks the Windows XP application process to think that inet_pton is available and not prompting any errors.
Repository: https://github.com/ccy/WS2_32_XP
inet_ntop() was added to Winsock in Windows Vista, it does not exist in XP.
Clearly, Embarcadero has added new code to the RTL in 10.2.2 that is calling inet_ntop() statically instead of dynamically. Code that did not exist in the RTL in 10.2.1. That is why the error is happening when loading 10.2.2's RTL package on XP.
There is nothing you can do about that. If you must run your app on XP, (which Embarcadero dropped support for way back in XE3), then you can't use the 10.2.2 RTL.
All,
I was able to solve the problem by creating a package with all the necessary units embbed.
Then the executable and the other BPL (modules) referring to this single new package.
It worked again in win XP!
Thank you all for the support
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.
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 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.