I try to add an icon in my Delphi 5 project and compile/link it, but get the following error:
"[Error] RLINK32: Out of memory!"
What is the problem?
The icon is at http://www.shuling.net/temp/Project2.zip
Your icons include large style 256px icons that were introduced in the Vista time frame. The Delphi 5 tooling is incapable of linking them. As I recall, the brcc32 from Delphi 5 cannot handle these icons because 256px icons are represented in a .ico file as having size 0. They are also stored with PNG compression to keep the size manageable. The brcc32 from Delphi 5 knows nothing of this and simply cannot handle it.
When I was linking such icons to my old Delphi 6 projects I used the Microsoft resource compiler, rc.exe to compile the resources. The Delphi linker from Delphi 6 was able to link the compiled .res files.
I'm not sure whether or not the Delphi 5 linker will be able to do even that. If not then you will need a post-build action to link the resource to the file. However, if I recall correctly, all I had to do was use rc.exe to compile the .rc file to .res, and then let Delphi link that.
So, in summary you need to:
Compile the .rc file with a modern resource compiler, for example rc.exe.
Link the resulting .res file in the usual way with $R if Delphi 5 can do so. If it cannot, use a separate post-build too to link the .res file.
Related
I'm trying to generate a multi-size icon file to my Delphi app, so Windows will choose the best size to show in each situation.
Following the official support instructions at https://docwiki.embarcadero.com/RADStudio/Sydney/en/Creating_and_Deploying_App_Icons
Storing Your Icon Files into an Icon Container
Once you have your app
icon in all the resolutions that a target platform requires, for
desktop platforms you must then archive the different resolutions of
your icon into a single file, an icon container, that you can deploy
along with your application.
For Windows, you must create an .ico icon container file. See How to
make/get a multi size .ico file?."
It directs to this Stack Overflow question :
How to make/get a multi size .ico file?
I followed the instructions exactly as described and could get a multi-size icon file using ImageMagick.
Problem is , when i try to compile my resource file using BRCC32, i get this error :
[BRCC32 Error] icon.rc(2): Allocate failed
Here is the contents of my RC file :
LANGUAGE LANG_NEUTRAL, SUBLANG_NEUTRAL
MAINICON icon "myapp.ico"
If i go to Project > Application > Icons, i can load the myapp.ico without problems, but due to the nature of my project, i need to use a resource file instead.
Please help, i'm stuck on this issue for days.
Thanks
From the documentation on resource compilers:
Both C++Builder and Delphi give you a choice of resource compilers. On the Project > Options > Resource Compiler dialog box, you can select either of the following:
BRCC32.exe, the C++Builder resource compiler
RC.exe, the Microsoft platform SDK Resource Compiler
RC supports Unicode characters in resource files and file names, as well as new Vista resource types such as icons with alpha channel.
Hence, if you need Vista icons, you need to change to the RC compiler.
I was assigned to make a small modification in a Delphi project.
To register that mod, my boss told me to increment the build number in Project options > Version Info.
I did that, but after compiling and building, when I look at the file properties, file version is not updated. The exe file was indeed compiled (I checked the modification date and it matches the time of build). The version number in the final EXE is unchanged, and not equal to the number I set in Version Info tab.
When I search Google about this, the only results I could find was tutorials to use this version feature and people with problems enabling it.
I tried reopening the project, deleting the generated EXE and rebuilding, removed the .RES file (the build fails because there's no RES file) and commented out the {$R *.RES} directive (no Version Info is included at all).
I'm not the original developer of this project, and the original one is not available anymore.
I think this could be related to this post, but it is from another Delphi version, and I couldn't find a dproj file in my project.
So, anyone knows whats wrong? Is it some kind of bug or am I missing something? Is there another option I should change so this option takes effect?
Use build instead of compile... it have no shortcut, you find it in Project menu (under compile)
I am trying to resolve this compile error, occuring only in Debug config, and only in the case described below:
[dcc32 Fatal Error] MyIndyTCPChannel.pas(22): F2051 Unit IdIOHandlerSocket was compiled with a different version of IdGlobal.IdDisposeAndNil
I am working on a very large Delphi codebase, with 2.5 million lines of in-house code, and 3 million lines of component code, which includes several large commercial Delphi component suites (Developer Express, TeeChart, and others), and a large number of open source delphi components as well, plus a fairly large in-house developed set of components, numbering 252 packages, of which about 140 are designtime+runtime or designtime, and the others are runtime packages (which are also loaded, into the IDE at runtime, by DLL-dependencies in their associated designtime package).
Our main library path has been optimized down to be small as can be, and it contains the paths that Delphi ships with as standard, plus three more we added, the primary one is a single "OurCompanyLibraryDCU" folder, which contains underneath it folders for the two platforms and two configurations that we use:
c:\dev\OurCompanyLibraryDCU\Win32\Release
c:\dev\OurCompanyLibraryDCU\Win32\Debug
c:\dev\OurCompanyLibraryDCU\Win64\Release
c:\dev\OurCompanyLibraryDCU\Win32\Debug
Each of the above folders contains the set of BPL, DCP, and DCU files in a single folder, for that platform/config combination.
A macro like the following, in the project options is used, so we can change platform, and config, and have the directories resolve correctly:
$(OURCOMPANYLIBRARYDCU)\$(Platform)\$(Config)
OURCOMPANYLIBRARYDCU is an environment variable and $(X) is the syntax to expand an environment variable, in the context of the Delphi IDE.
I am trying to get the most important and largest VCL Application project (call it BigApp.dproj) to build so that the project search directory only contains our APPLICATION source folders and does not need the project search path to contain all our third party component LIBRARY source code. To do that, we need to link against the debug DCUs, or release DCUs.
So far we have everything working except for the case where you have both Debug and Release DCUs available. The release DCUs are in the library path, and the debug DCUs are in the Debug DCU path, in the IDE settings. Confronted with the choice between these two libraries, Delphi's linker appears to fail, whenever both sets of DCUs exist, with errors in this form, when I click Build, and the Build Configuration is set to Release, I get F2051 errors. The ordinary cause of an F2051 error is that multiple incompatible binary DCUs exist and are both accessible, and the linker is failing to make it all work. However, when you want both Debug and Release DCUs both in the library path, I thought that this sort of thing would not occur, due to the Linker selecting the debug or release DCUs for you.
If I have not build the Debug DCUs, the above problem does not occur. I suspect that my Debug DCUs are subtly "invalid" or that the Debug-DCU-selection algorithm inside Delphi is not working, but have no idea why, or how to fix this.
Multi-part-Question:
A. Is having a single folder for each platform/config combination, containing the DCU, BPL, and DCP in a single folder, and then added to the IDE Library Path known to cause problems? Do I need three sub-folders, making a total of 12 folders for every platform+config+filetype, or can I keep them together by platform+config?
B. In a package compilation situation, is it okay to have the IDE Library path contain the OurCompanyLibraryDCU folder, and also have that folder configured as the DCP Output Directory, Package Output Directory, and Unit Output Directory? My concern is that by having input folder and output folders the same, there is a case where the compiler could be failing to rebuild a Unit from .pas source, and simply linking the prior compile's DCU.
C. If I'm going about this wrong, how instead, shall I prevent the over 2.5 million lines of component LIBRARY code from being compiled from source each time I build my BigApp, instead only link them via DCU, and still have the debug and release dcus work properly?
D. I can get past the original error if I go to the Win32\Debug folder and delete IdGlobal.dcu. This suggests to me that my package compilation (for debug config) is producing an INVALID IdGlobal.dcu. Is that even possible? Can delphi silently output garbled DCUs?
Notes: I'm not using, and can not use Runtime Packages, to deal with the application size problems.
Update: The first thing I should have done here is verify that ZERO additional DCU files are ANYWHERE on my harddrive, ANYWHERE. That's the standard F2051 error advice. I'll update this question after I've taken care of that. It appears possible that Delphi will itself COPY a DCU from one place to another, or that a bogus DCU that is NOT in the CURRENT search path might have been in some other project's search path. A kind of bucket-brigade of bad-DCU-copies can occur. I'll update the question once I'm sure what kind of bad-DCU-generations-or-copies are occuring.
Update 2: I have now guaranteed that no additional copies of IdGlobal.dcu exist before building, and the problem still reproduces. So the question then turns on the compiler options used when building the IdGlobal.dcu, versions the compiler options used when building BigApp.dproj in Debug build.
Update 3: Although all my package compiles appear to complete without error, it seems they were not using a correct library search path, during the time when the DCC32.exe or MSBUILD.exe is being launched to build the packages. This library path inconsistency issue appears to be the core issue, thanks to Sir Rufo for pointing that out.
Perhaps I can shed some light on the order of search paths presented to the compiler, which should make clear why the problem happens in the first place and can be cured (at least in your situation) by adding the Debug DCU path at that specific location. All these observations were made with XE7.
There are several places in the IDE where you can specify search paths:
Library path (Delphi-Options - Library)
Translated Library path (Delphi-Options - Library-Translated)
Debug DCU path (Delphi-Options - Library)
Translated Debug DCU path (Delphi-Options - Library-Translated)
Search path (via Project Options)
When the Library language is set to English, those pathes are given to the compiler in the order 5,1 or 3,5,1 depending of the setting of Use debug .dcus. This is already a bit weird as the debug dcu path takes precedence over the project search path.
So f.i. to make the compiler find our own dcu files of a newer Indy version, we have to place the corresponding paths in front of the paths under 1 and 3.
Now things get complicated when the Library language is set to something different than English. In this case the translated paths come into play resulting in the order 2,5,1 or 4,3,2,5,1 depending of the setting of Use debug .dcus.
To make the above example with a newer Indy version work, you have to tweak the translated paths, too.
The culprit lies in CodeGear.Delphi.Targets, which places the paths in this order. I was able to modify this file so that the natural order of paths is used: 5,2,1 or 5,4,3,2,1. If anyone can confirm that I am allowed to show these changes here I will do. Perhaps I can provide a patch only.
Update: Here are the changes of CodeGear.Delphi.Targets from XE7 as shown by Mercurial
## -122,20 +122,19 ##
<DcpFilename Condition="'$(DcpFilename)'!='' And !HasTrailingSlash('$(DcpFilename)')">$(DcpFilename)\</DcpFilename>
<DcpFilename Condition="'$(DcpFilename)'!=''">$(DcpFilename)$(MSBuildProjectName).dcp</DcpFilename>
- <UnitSearchPath Condition="'$(DCC_UnitSearchPath)' != ''">$(DCC_UnitSearchPath);$(DelphiLibraryPath)</UnitSearchPath>
- <UnitSearchPath Condition="'$(DCC_UnitSearchPath)' == ''">$(DelphiLibraryPath)</UnitSearchPath>
-
+ <UnitSearchPath>$(DelphiLibraryPath)</UnitSearchPath>
<UnitSearchPath Condition="'$(DCC_TranslatedLibraryPath)' != ''">$(DCC_TranslatedLibraryPath);$(UnitSearchPath)</UnitSearchPath>
<UnitSearchPath Condition="'$(DCC_DebugDCUs)'=='true' And '$(DelphiDebugDCUPath)'!=''">$(DelphiDebugDCUPath);$(UnitSearchPath)</UnitSearchPath>
<UnitSearchPath Condition="'$(DCC_DebugDCUs)'=='true' And '$(DCC_TranslatedDebugLibraryPath)' != ''">$(DCC_TranslatedDebugLibraryPath);$(UnitSearchPath)</UnitSearchPath>
-
+ <UnitSearchPath Condition="'$(DCC_UnitSearchPath)' != ''">$(DCC_UnitSearchPath);$(UnitSearchPath)</UnitSearchPath>
+
<___ResourcePath Condition="'$(DCC_ResourcePath)' != ''">$(DCC_ResourcePath);$(DelphiLibraryPath)</___ResourcePath>
<___ResourcePath Condition="'$(DCC_ResourcePath)' == ''">$(DelphiLibraryPath)</___ResourcePath>
+ <___ResourcePath Condition="'$(DCC_TranslatedResourcePath)' != ''">$(DCC_TranslatedResourcePath);$(___ResourcePath)</___ResourcePath>
<__ResourcePath Condition="'$(DCC_UnitSearchPath)' != ''">$(DCC_UnitSearchPath);$(___ResourcePath)</__ResourcePath>
<__ResourcePath Condition="'$(DCC_UnitSearchPath)' == ''">$(___ResourcePath)</__ResourcePath>
<ResourcePath Condition="'$(BRCC_OutputDir)' != ''">$(BRCC_OutputDir);$(__ResourcePath)</ResourcePath>
<ResourcePath Condition="'$(BRCC_OutputDir)' == ''">$(__ResourcePath)</ResourcePath>
- <ResourcePath Condition="'$(DCC_TranslatedResourcePath)' != ''">$(DCC_TranslatedResourcePath);$(ResourcePath)</ResourcePath>
<NameSpace Condition="'DelphiNamespaceSearchPath'!=''">$(NameSpace);$(DelphiNamespaceSearchPath)</NameSpace>
Now I understand a source for this problem. Please upvote Sir Rufo as he put me in mind of the solution.
It is this: I was invoking DCC32.exe to compile packages (using .dpk, but no .dproj file, and not invoking msbuild to compile these packages). When I built these, I was not inserting the Debug DCU path to the head of the library path passed in via -I parameters to DCC32.exe.
Once the DCC32.exe package compilation Library Search path has the Debug DCU folders FIRST, it works.
If anyone is interested in such a package system, I am planning to open source this package build system, as part of a relaunch of the WANT project originally built by Juancarlo Anez, which I will probably call by a new name. I'll update this answer once a working demo of a component build system is available.
A brief outline of a working system to meet the requirements I asked in my question:
You will need a file (could be xml, ini, json file) that defines a list of packages to build.
You will need to invoke MSBUILD or DCC32.exe on each of these. You could write your own code, or you could use mine, which I will open source when I can.
You will need to include the Debug DCU DPROJ into the library path as the first items, ONLY when invoking the Debug item builds.
You will want to use the $(OURCOMPANYLIBRARYDCU)\$(Platform)\$(Config) macro in your project search paths and library paths.
In your Delphi IDE, you will want to hard-code $(OURCOMPANYLIBRARYDCU)\$(Platform)\Release as a path within the Library path.
In your Delphi IDE, you will want to hard-code $(OURCOMPANYLIBRARYDCU)\$(Platform)\Debug as a path within the Debug DCU path.
My first question here - this is new install of Delphi XE3. I thought animated GIF support was now built in to Delphi (since 2007?).
When I drop a TImage on my form, all is good until I populate the Picture field with an animated GIF file. As soon as I do that, the IDE adds the following to my uses clause
uses ... , Vcl.Imaging.GIFImg, GIFImage;
At that point, the IDE and compiler say it can't find GIFImage.dcu
[dcc32 Fatal Error] pco.pas(7): F1026 File not found: 'GIFImage.dcu'
I've searched my system and I don't find a GIFImage.dcu file anywhere. There are some TGIFImage files in some of the RAD Studio folders - like .bpl, .bpi, .dcp, .lib, and two .hpp files - one for both TGIFImage and GIFImage.
If I go do a download of the GIFImage stuff from Finn's site here http://www.tolderlund.eu/delphi/, and then put the GIFImage.pas file in my project, the situation resolves itself.
But according to this post How to use Animated Gif in a delphi form, GIFImage is now built in to Delphi, so I don't think I should have to do that ... So what am I missing here? TIA.
The name of the unit in XE3 is Vcl.Imaging.GIFImg. The TGIFImage class is defined in that unit.
There is no GIFImage unit in XE3. Simply remove all references to that unit.
I guess at some point the unit was renamed. Probably when it was taken on by Embarcadero and incorporated into Delphi.
If I go do a download of the GIFImage stuff from Finn's site here http://www.tolderlund.eu/delphi/, and then put the GIFImage.pas file in my project, the situation resolves itself.
Don't do this. Delete those files. If you go down that route you will have two versions of the same GIF code.
In Delphi 7, an image editor program is included, which can read and write .dcr files, which are merely binary resource files (.res files) with a different extension, which by convention indicates that the .dcr file contains a compiled resource with named bitmap resources that have names corresponding to your component names (a bitmap resource named TMYCOMPONENT for a component named TMyComponent). These bitmaps are where the "icons" used to put an icon on the delphi component palette, and on your form or data-module when you drop a non-visual component on it, come from.
Fast forward 10 years to Delphi XE, and I am trying to make component icons using a bitmap file, and an RC file, and have that build to a .DCR file, as part of the Delphi IDE.
It should be simply a matter of adding an .Rc file and a declaration like this in the .dpk (package source) file, like this:
{$R mypackageicons.rc mypackageicons.dcr}
A sample .rc file containing a component icon:
// COMPONENT ICON RESOURCES
TMYCOMPONENT BMP "TMYCOMPONENT.BMP"
However I can not get this to work. It seems that you get some bizarre RLINK32 errors, and IDE crashes in borlandmm.dll, when I try it:
[DCC Error] E2161 Error: RLINK32: Unsupported 16bit resource in file "C:\temp\compicon\COMPONENTICONS.rc"
[DCC Fatal Error] F2084 Internal Error: AV21515155-W06000D07-1
The bitmap file in question is a simple 256 color bmp file size 24x24 pixels, and I have also tried 16 color bitmaps, with no luck. It seems to me that the ImageEdit program is the only way that I know of that I can use to create Delphi component icons.
What am I missing out on?
Update: The external tools are a nice solution for people who don't have access to the Delphi 7 image editor, and may in fact be superior, but I would prefer to do this using only what ships with Delphi, because it seems that it should be possible using just one {$R} declaration, a text file, and a bmp file made with paintbrush. Surely they didn't omit to make a way to make component icons, with this great big 1.5 gigabyte developer tool! .. update2: And there is a way; Rudy V. found it.
I have used and had great success with:
Colin Wilson's XN Resource Editor
Anders Melander's Resource Editor
Update
I just tried the following, in XE, and was successful.
I created a new component, TNewAnimate, in NewAnimates.pas.
I added TNewAnimate.pas to dclusr.dpk.
I added a bitmap (called TMRUComboBox.bmp, I just had that around anyway) using the Project → Resources and Images... dialog to the .dpk and gave it the name TNEWANIMATE.
I re-installed dclusr.dpk.
The source file for dclusr.pdk got a new entry {$R *.dres} (note the extension). I could see the TNewAnimate in the Samples palette with the glyph in TMRUComboBox.bmp.
I located dclusr.dres in the same directory as dclusr.dpk (which is normally under C:\Program Files, but not in my setup). I tried to open it with XN Resource Editor, but that refused to open it with a cryptic error message. It is not a normal .res file, it seems.
Try Resource Editor. A nice replacement for old Image Editor.
First add 'mypackageicons.rc' file to the project, this produces 'mypackageicons.res' at compile time (see related SO answer to the question "Including resource file in a project by .RC file rather than .RES file").
Also include {$R mypackageicons.res mypackageicons.dcr} to the component unit (or to the .dpk). This does not produce a '.dcr file', but sets the icon for the component.
Note that my test with a 'BMP' resource failed. I used 'BITMAP' as resource type.
I have investigated the previous responses using Delphi XE5 upd2. Not much success. So I tried to build a new solution and found one derived from previous answers.
In short:
1. Create your bitmap using Windows Paint program.
2. Create a resource script file with the bitmap.
3. Compile the script with BRCC32 to produce the dcr file
4. Include the dcr file into the package source
5. Recompile/Install the package
To automate this, it is enough to add the BRCC32 command line into the package project "pre-build events". This way, you dcr file will be recreated before each build.
For a detailed description, see my blog at http://francois-piette.blogspot.be/2014/02/howto-create-dcr-file-for-your-delphi.html