Delphi DFM not found - delphi

I am having one xyz.pas file reference in my project. But that file is not with me. I am having the xyz.dcu and xyz.obj file of that xyz.pas file.
When I tried to compile the project I have got the Error "xyz.dcu not found". So i have included the path of xyz.dcu in Search path. Now I am getting error "xyz.dfm not found".
Please suggest me the solution. Is it possible to compile the project with only .dcu and .obj files?
Thanks in advance.
Regards,
Naren

I hope you haven't lost your work.
Simplified, Delphi works like this:
PAS+DFM => DCU
DCU+RES => EXE
More about Delphi files at the end of this answer.
You can compile the project if you only have the DCU file. First, remove the PAS file from your folder else Delphi will try to recompile it (and in order to recompile it, it needs the DFM file).
I don't think the Obj file will be of any use to you.
The DFM file is very very important for your project but yet not critical important. If you are in deep need, you can still go on without it as it can be reconstructed manually based on information you have in the PAS file and based on the way the application's GUI looks (if you have ever seen it running).
Here is the trick (involves some work):
Just create a new form and then look at the top of your original PAS file for the declaration of the form. It may look like this:
TYPE
TYourForm = class(TForm)
xLabel: TLabel;
yButton: TButton;
etc
etc
end;
Then put all those controls back to your new form and name them exactly as they are named in the PAS file (xLabel, yButton, etc). Arrange them to resemble the original GUI. When done, replace the new created PAS file with your original PAS file. IMPORTANT: the name of the DFM and PAS file should match. Compile and you are done! The rebuilt GUI may not look EXACTLY as the original one, but it should do it.
Hint:
There are tools that can extract the DFM file from DCU/EXE.
Here are some of them: www.delphi2.software.informer.com/download-delphi-extract-dfm
This will help you a lot!
.PAS - Delphi Source File
PAS should be stored in Source Control
In Delphi, PAS files are always the source code to either a unit or a form. Unit source files contain most of the code in an application. The unit contains the source code for any event handlers attached to the events of the form or the components it contains. We may edit .pas files using Delphi's code editor. Do not delete .pas files.
.DCU - Delphi Compiled Unit
A compiled unit (.pas) file. By default the compiled version of each unit is stored in a separate binary-format file with the same name as the unit file, but with the extension .DCU (Delphi compiled unit). For example unit1.dcu contains the code and data declared in the unit1.pas file. When you rebuild a project, individual units are not recompiled unless their source (.PAS) files have changed since the last compilation, or their .DCU files cannot be found. Safely delete .dcu file because Delphi recreates it when you compile the application.
.DFM - Delphi Form
DFM should be stored in Source Control
These files are always paired with .pas files. Dfm file contains the details (properties) of the objects contained in a form. It can be view as text by right clicking on the form and selecting view as text from the pop-up menu. Delphi copies information in .dfm files into the finished .exe code file. Caution should be used in altering this file as changes to it could prevent the IDE from being able to load the form. Form files can be saved in either binary or text format. The Environment Options dialog lets you indicate which format you want to use for newly created forms. Do not delete .dfm files.
source: delphi.about.com/od/beginners/a/aa032800a.htm

If you are still in the possesion of the executable, then you can extract your complete and original DFM file from the application resources by any arbitrary resource manager. For example: XN Resource Editor. In the RC DATA category, there will be an item called TXYZ.

Delphi 20xx/XE
Note that Delphi saves old versions of your files in a hidden subdir of your project dir called __history.
In that dir are saved versions of your .pas, .dfm and other project files.
These files are created every time you save a change to disk.
Do a search on your harddisk for all files, (including hidden ones) named *.~*~ this should bring up any backup source files you may have.
They will miss the last change(s) you made, but at least you will not have to do everything all over again.
Delphi 7 and before
Delphi 7 saves these files in the same dir as your project files with a .~ extension.

DFM-Files hold the "visual" aspects (controls, components, properties, visuals, data...) of a (say) form. If the PAS-File (or the compiled DCU-File) needs the DFM, you have to have it, or you get this error. There is no other way than to have the DFM, i think.
Correction (as written below, sorry!): you can compile with only the DCU-file if you remove the PAS-file and provide ONLY the DCU-File. In this case the DCU-File must be compiled with the same compiler-version to be linked into the App, because the compiler can not recompile the DCU.

This is pretty late, but here's what I came with.
My directory stucture is like this
/ Project
/ Source
/ Unit1.pas
/ Packages
/Delphi2010Berlin
/ MyPackage1.dpk
/ MyPackage2.dpk
/ Library
/ Delphi2010Berlin
/ Win32
/ Debug
/ Release
In the /Project folder, i created a .bat file named 'dfmcopy.bat'
All it contains is
#echo off
for /r %1 %%x in (*.dfm) do #copy "%%x" %2 /Y >NUL
Then, in my post build event for my .bpl
./../../dfmcopy.bat $(PROJECTPATH)\..\..\Source $(PROJECTPATH)\..\..\Library\$(Platform)\$(Config)
This will recursively copy all .dfm that are contained in the /Source folder into the /Library/{DelphiVersion}/{Platform}/{Config} folder
One caveat is that if you have multiple projects that have this post build event, dfms might be copied over and over for each project. Don't know if that can pose any issue now.

I use apache ant to build delphi project.
I fix the "dfm not found error" by deleting all dcu files and seperating compiler output files from source files.
The problem is probabily caused by wrong path of dcus files.
<project name ="app1" default = "run">
<property name="delphipath" value="your delphi path"/>
<property name="source" value="C:/ws4d/TStateMachine-master/Tests"/>
<property name="dunit" value="C:/ws4d/dunit-svn"/>
<property name="DCUOUT" value="C:/ws4d/TStateMachine-master/Tests/BIN"/>
<target name="run">
<!-- Compile with Delphi 6 -->
<apply executable="${delphipath}/bin/dcc32.exe" failonerror="true" output="build-dxe10.log" >
<!-- rebuild quiet -->
<arg value="-B"/>
<arg value="-Q"/>
<!-- file paths -->
<arg value="-I${source};{dunit}/src"/>
<arg value="-U${source};{dunit}/src;{delphipath}/lib/win32/release"/>
<arg value="-R${source};{dunit}/src;{delphipath}/lib/win32/release"/>
<arg value="-O${DCUOUT};"/>
<arg value="-N${DCUOUT}"/>
<arg value="-E${DCUOUT}"/>
<!-- all *.dpr files in current directory -->
<fileset dir=".">
<patternset><include name="*.dpr"/></patternset>
</fileset>
</apply>
</target>
</project>

Related

What is the difference between the -i and -u parameters to the dcc command-line compilers?

What exactly is the -i option of the Delphi dcc command-line compilers (dcc32.exe, dcc64.exe, dcclinux64.exe and others)? As opposed to -u? Help just states this briefly (and Embarcadero documentation does not seem to expand upon the subject):
-I<paths> = Include directories
-U<paths> = Unit directories
For a while, I thought that -u is for including source code and -i for including precompiled .dcu files, but that does not seem to be the case. I also see cases where -i imports source code and -u imports .dcu files, and also that seems to work just fine. Another thought is that -u is meant to be the counterpart of the project's Search path in the Delphi IDE, and -i the counterpart of the Delphi IDE's global Library path, but that does not seem conclusive, either.
When should I use one or the other, -i or -u?
The Remarks section of this page http://docwiki.embarcadero.com/RADStudio/Sydney/en/Include_file_(Delphi) begins
The $I parameter directive instructs the compiler to include the named file in the compilation. In effect, the file is inserted in the compiled text right after the {$I filename} directive.
The default extension for filename is .pas. A filename specified with no file extension always gets the .pas extension. If the filename does not specify a directory path, then, in addition to searching for the file in the same directory as the current module, Delphi searches in the directories specified in the Search path input box on the Delphi Compiler page of the Project > Options dialog box (or in the directories specified in a -I option on the command line compiler). ..."
The important thing to understand is that this is not talking about searching for source files in general, but rather for single files named in a source file by an
{$inc }
or
{$include }
directive in a source file. For example
unit SomeUnit;
{$inc SomeIncludeFile}
interface
[...]
Files named inside an {$inc} or {$include} directive are known as "include files" - hence the title topic of the quoted page. Subject to the restriction noted in the final paragraph of the Remarks, the directive can appear pretty much anywhere in a source file and, during compilation, the compiler substitutes the contents of the named file for the directive (including the filename). The support for include files in Turbo Pascal pre-dates its support for units and was primarily to ensure that two or more source files could behave as if they contained identical text, for example shared code or definitions.
The -i setting tells the compiler one or more folders in which to look for files such as SomeIncludeFile which are named by include directives the compiler encounters while compiling the source files in a project.
The -u setting tells the compiler where to look for unit files (e.g. .Pas and .Dcu ones) during a compilation.

DFM not found after reorganisation

I have a Delphi 7 project with this structure:
.dpr
foo.pas
*.pas
*.dfm
Bin/
debug/
Most of the source code, except for one file, is shared between other projects (although this is not relevant), so I did some reorganisation that looks like this:
.dpr
UniqueFile/
foo.pas
Common/.pas
*.pas
*.dfm
Bin/
debug/
I changed the paths in the .dpr with the new structure, but when I try to compile for some reason it cannot find one of the .dfm files in Common folder. The error shown is:
[Error] File not found: 'SomeFile.DFM'
However, both the .pas and the corresponding .dfm are in that folder.
Did I miss some configuration?
EDIT: This file is included in the .dpr file like so:
uses
...
SomeFile in 'Common/SomeFile.pas',
...
EDIT2: I've copied only the SomeFile.dfm file to the root folder, and it's compiling. For some reason it's still looking for that file in the old path?
EDIT3: I've included what #ken-white has pointed out but no luck. So now the .dpr looks like so:
uses
...
SomeFile in 'Common/SomeFile.pas' {ChildFrame},
...
I've also double-checked this line in SomeFile.pas:
{$R *.DFM}
Another thing that I should point out is that the Build option works fine, but not the compiling.
You're missing the entry for the form in your .dpr file that tells the IDE there's a .dfm associated.
When you create a new VCL Forms application, the IDE writes the following entry to the project file:
uses
Forms,
Unit1 in 'Unit1.pas' {Form1};
The information is the {Form1} tells the IDE to look for a .DFM file that contains the form information. You've said that the .pas file is in your new Common folder, but not told it that it should also look for a .dfm there as well. The IDE looks for it in the project folder instead, and can't find it there. Until, of course, you copy it into the project folder instead. :-)
Change your .dpr to read
uses
...
SomeFile in 'Common/SomeFile.pas' {FormClass},
replacing {FormClass} with the name of the form variable from your SomeFile unit instead.
Looks to me that your issue (at least as of now) is that you are using a forward slash instead of a backslash.
uses
...
SomeFile in 'Common/SomeFile.pas' {ChildFrame},
...
...should instead be...
uses
...
SomeFile in 'Common\SomeFile.pas' {ChildFrame},
...

Delphi 7 and .dfm files get the forms displayed?

I'm a beginner. I have received a .rar file containing a bunch of files. I think that they are used to generate Forms.
Here's an example:
BackupManager.dfm
BackupManager.pas
WaveControl.dfm
WaveControl.pas
So, can anyone help me understand exactly how to use them?
A .dfm file contains the property values and sub object definitions of a Form. The .pas file that has the same base filename as the .dfm file contains the Delphi Pascal source code for the Form, its event handlers, etc.
To use these files, simply create a Delphi VCL Forms project and add the .pas files to the project. Each .pas file should have a {$R *.dfm} compiler directive in it to link to its associated .dfm file.
The compiler will compile each .pas file into a .dcu file and link it into the final executable, and will also create a separate binary resource for the content of each .dfm file and link them into the executable as well.
When the executable is run and it tries to create an instance of a Form class (either automatically at startup, or explicitly in code), the RTL will automatically load the appropriate DFM resource and parse it to construct the necessary sub objects, assign their property values, and hook up their event handlers.

How to harvest XNA content files using WiX?

Ideally I'd be grabbing the outputs from the project spec itself, but heat.exe doesn't seem to support contentproj files as a project type, nor does it pick up the content if I pass in the game's main csproj.
Currently I have a pre-build step calling heat on the output folder, but that (a) feels dirty, and (b) produces a bunch of File tags referencing the source paths relative to the output folder, such that the build fails when it can't find them relative to the WiX project's folder.
I should note that I'm using Votive and my project layout looks like this:
- Main solution
- XNA "Metaproject" Folder
- Game
- bin/x86/Release (GameContent output appears here)
- GameContent
- WiX Project
I would very much like to minimize the number of times I have to specify a path like "../../Game/Game/bin/x86/Release/Content", because that's error-prone and depressing to type out. Prods in the right direction appreciated!
Assuming a contentproj is just a collection of files, what you can do is add the harvesting directly within the wixproj that is creating the installer:
<PropertyGroup>
<HarvestDirectoryNoLogo>true</HarvestDirectoryNoLogo>
<HarvestDirectorySuppressFragments>true</HarvestDirectorySuppressFragments>
<HarvestDirectorySuppressUniqueIds>true</HarvestDirectorySuppressUniqueIds>
<HarvestDirectoryAutogenerateGuids>true</HarvestDirectoryAutogenerateGuids>
</PropertyGroup>
<ItemGroup>
<HarvestDirectory Condition=" '$(Configuration)|$(Platform)' == 'Debug|x86' "
Include="$(SolutionDir)\GameContent">
<DirectoryRefId>INSTALLDIR</DirectoryRefId>
<SuppressRootDirectory>true</SuppressRootDirectory>
<PreprocessorVariable>var.GameContentDir</PreprocessorVariable>
<ComponentGroupName>GameContent</ComponentGroupName>
</HarvestDirectory>
</ItemGroup>
You will need to add this manually to the wixproj file and you can repeat the HarvestDirectory for each directory if you require more than one.
To set the var.GameContentDir pre-processor variable edit the DefineConstants property:
<DefineConstants>GameContentDir=$(GameContentDir);</DefineConstants>
which will set the pre-processor var to the msbuild property:
<GameContentDir>$(SolutionDir)\GameContent</GameContentDir>
which means you can then modify this dependant on the build configuration. If you don't need to modify the path, just set a static value in the <DefineConstants> property.
This will then generate a wxs file in the obj directory each build which is then included assuming you have included the ComponentGroupName. If you have included the one you previously generated in your wixproj remove it as you will get conflicts if the ComponentGroupName is the same.

VCL-Styles embedded in dll?

How do I embed Delphi XE2 VCL-Styles in a dll? The Application - Appearance page is not visible in project settings for DLL-projects.
I tried defining them in a rc-file included with a $R directive which works but if there is a better way I'd like to know.
RC-file example:
GOLDENGRAPHITE VCLSTYLE "C:\Program Files (x86)\Embarcadero\RAD Studio\9.0\Redist\styles\vcl\GoldenGraphite.vsf"
CARBON VCLSTYLE "C:\Program Files (x86)\Embarcadero\RAD Studio\9.0\Redist\styles\vcl\Carbon.vsf"
In particular having to specify the full path to XE2-installation folder is something I want to avoid.
Another options which you can use
1) Using the Resource dialog.
2) Editing the dproj file of your dll
under this key <PropertyGroup Condition="'$(Base)'!=''">
Add one Entry VCL_Custom_Styles for the vcl styles
<VCL_Custom_Styles>"Amakrits|VCLSTYLE|$(PUBLIC)\Documents\RAD Studio\9.0\Styles\Amakrits.vsf";"Amethyst Kamri|VCLSTYLE|$(PUBLIC)\Documents\RAD Studio\9.0\Styles\AmethystKamri.vsf";"Aqua Graphite|VCLSTYLE|$(PUBLIC)\Documents\RAD Studio\9.0\Styles\AquaGraphite.vsf"</VCL_Custom_Styles>
It works for us also (thanks Rodrigo). Just a couple of details
Don't expect to find the VCLSTYLE on the list of the Resource Type Combo Box, you have to type it manually.
Don't miss to initialize the style in your DLL, we add the next code to the FormCreate event:
TStyleManager.SetStyle('Carbon');
To access correctly to the Style added as a resource check you are adding to the uses clause both units: Vcl.Themes, Vcl.Styles.

Resources