Related
I have a couple of newbie questions that I cannot seem to find the answers to.
Variables
I have noticed that in some apps they declare variables in the private or public sections of the form type however in other apps they declare them in the implementation part of the form, is there a reason for this or is it just user choice?
Procedures / Functions
Again I have noticed that in some apps procedures / Functions are Declared in the private / public part of the form type and then when created they are prefixed by the form name EG
Procedure Tform1.testproc;
Begin
Blah
End;
Whereas in other apps they are not declared in the form type and are not prefixed with the form name, is there a reason for this? Also which is the best way?
Using other units
Is there a reason why some apps add other units normally user created to a uses clause after the form implementation section whereas other apps add them to the uses clause # the top of the form unit?
Any help / answers to the above questions would be great
Many thanks
Colin
It all depends on visibility.
Types, variables, constants, procedures, and functions declared in the interface section of a unit (but outside of classes and other type definitions) are visible to other units, whereas types, variables, constants, procedures, and functions declared in the implementation section of a unit can only be used in the very same unit (and only below the declaration). Hence, if you need types/variables/functions/... in a particular unit but do not expect the identifiers to make sense outside the unit, then it is a good idea to declare them right before they are needed, in the implementation section.
Further, when it comes to classes, their identifiers can be declared as private, strict private, public, protected, and published. This is again due to different kinds of visibility. Private identifiers can only be used inside the class itself (or other classes defined in the same unit, unless strict private), and so on.
Also, notice this:
unit Unit1;
interface
uses
Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms,
Dialogs;
type
TForm1 = class(TForm)
private
{ Private declarations }
alpha: integer;
public
{ Public declarations }
end;
var
Form1: TForm1;
var
beta: integer;
implementation
{$R *.dfm}
end.
Since alpha is a member of the class TForm1, every instance of this class, that is, every object of this form (that is, every form created of this class) will have its own alpha variable. On the other hand, beta, being declared in the unit outside of any class, is "one per unit", that is, every TForm1 object will see the same beta. (And then there are "class variables" and such. Please see the documentation for more details.)
(Also, you probably already know this, but in a case like
unit Unit3;
interface
uses
Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms,
Dialogs;
type
TForm3 = class(TForm)
procedure FormCreate(Sender: TObject);
private
{ Private declarations }
public
{ Public declarations }
end;
var
Form3: TForm3;
implementation
{$R *.dfm}
procedure TForm3.FormCreate(Sender: TObject);
begin
beep;
end;
end.
you do not have two functions named FormCreate, but only one. The first reference to this function is the declaration, which is part of the class declaration in the interface section, which is what other classes and units will see. The actual implementation of the FormCreate function (or its definition) is always in the implementation section. Indeed, other classes or units do not need to know the exact implementation of the functions in a particular class.)
Finally, I would like to recommend the official Delphi documentation, which is very good. Start at http://docwiki.embarcadero.com/RADStudio/en/Delphi_Language_Guide_Index.
Variables/procedures/functions
It all comes down to where the information is supposed to go.
If it's a method or variable specific to the instance of the form, then you have to declare it in the form type itself. If it applies to all instances of the form, then you put it in the implementation section which makes it global - it's not part of the type.
In many cases, you won't ever have more than a single instance of a single form at a time, so in that case, it generally doesn't matter where you put it, as far as the functionality is concerned - but it's considered good practice to put what you can in the form type, rather than in the implementation section. This is because it keeps the information associated with the form itself, instead of relying on global information which can basically be accessed from anywhere.
Uses
There are two different places to put the uses clause, and you've noticed both of them.
The reason this is needed is because the Delphi compiler is implemented as a single-pass compiler. This makes it fast, but it also means that you have to declare everything in advance, so it knows what to expect.
When using the uses clause after the implementation keyword, the unit is not read until after all of your types are declared. This allows you to have units refer to each other, i.e. Unit1 referring to Unit2 and Unit2 referring to Unit1, because all of the required definitions will be available before a dependency on the other is introduced. This is not possible if both refer to each other from their "top" uses clause.
Since you can be certain that the VCL units won't be referring to any of the units you have in your code, they are therefore safe to include at the top. The same cannot necessarily be said about units you create in your project, so it's safer to add them to the other uses clause.
It's all about Delphi's module system (modules are called units here).
When you declare something inside Interface part of the unit, it is visible to all other units.
Whereas Implementation is visible only for this unit.
And when dealing with classes, private / public relates only to members of this particular class.
Consider:
unit A
//------------------------------------------------
Interface
uses ... // modules on which *iterface* depends
// don't include here modules needed for implementation only
//------------------------------------------------
var visibleVar: Integer; // visible from other units
//------------------------------------------------
type VisibleType = class
public:
visibleMember: Integer; // visible from other units and classes
private:
invisibleMember: Integer; // invisible from other units, but
// visible to other classes in this unit
strict private:
reallyInvisible: Integer; // visible *only* inside this class
end;
//------------------------------------------------
//------------------------------------------------
//------------------------------------------------
Implementation
uses ... // modules on which *implementation* depends (and interface is *not*)
//------------------------------------------------
var invisibleVar: Integer; // can't reference to this from other units
//------------------------------------------------
type InvisibleType = class // can be referenced only from inside this module
public:
modulePrivateMember: Integer; // visible only inside module's implementation
private:
invisibleMember: Integer; // in *this context* essentially the same as "public"
strict private:
reallyInvisible: Integer; // same as in interface - it's just private
end;
This question already has answers here:
Delphi Enterprise: how can I apply the Visitor Pattern without circular references?
(4 answers)
Closed 8 years ago.
Is there a way of getting around circular unit references in Delphi?
Maybe a newer version of delphi or some magic hack or something?
My delphi project has 100 000+ lines of code mostly based on singleton classes. I need to refactor this, but that would mean several months of "circular reference" hell :)
I've been maintaining close to a million lines of legacy code for the past 10 years so I understand your pain!
In the code that I maintain, when I've encountered circular uses, I frequently have found that they are caused by constants or type definitions in unit A that are needed by unit B. (Sometimes it's also a small bit of code (or even, global variables) in Unit A that is also needed by unit B.
In this situation (when I'm lucky!) I can carefully extract those parts of the code into a new unit C that contains the constants, type definitions, and shared code. Then units A and B use unit C.
I post the above with some hesitance because I'm not an expert on software design and realize there are many others here who are far more knowledgeable than I am. Hopefully, though, my experience will be of some use to you.
It seems you have quite serious code design issues. Besides many signs of such issues, one is the circular unit reference. But as you said: you cannot refactor all the code.
Move all what is possible to the implementation section. They are allowed to have circular references.
To simplify this task you can use 3rd party tools. I would recommend
Peganza Pascal Analyzer - it will suggest what you can move to the implementation section. And will give you many more hints to improve your code quality.
Use the implementation section uses whenever possible, and limit what's in the interface uses clause to what has to be visible in the interface declarations.
There is no "magic hack". Circular references would cause an endless loop for the compiler (unit A requires compiling unit B which requires compiling unit A which requires compiling unit B, etc.).
If you have a specific instance where you think you cannot avoid circular references, edit your post and provide the code; I'm sure someone here can help you figure out how to get it fixed.
There is many ways to avoid circular references.
Delegates.
Way too often, an object will execute some code that should be done in an event instead than being done by the object itself. Whether it is because the programmer working on the project was too short on time(aren't we always?), didn't have enough experience/knowledge or was just lazy, some code like this eventually end up in applications. Real world exemple : TCPSocket component that directly update some visual component on the application's MainForm instead of having the main form register a "OnTCPActivity" procedure on the component.
Abstract Classes/Interfaces. Using either of them allow to remove a direct dependance between many units. An abstract class or an interface can be declared alone in its own unit, limiting dependancies to a maximum. Exemple: Our application has a debug form. It has uses on pretty much the whole application as it displays information from various area of the application. Even worse, every form that allows to show the debug form will also also end up requiring all the units from the debug form. A better approach would be to have a debug form which is essentially empty, but that has the capacity to register "DebugFrames".
TDebugFrm.RegisterDebugFrame(Frame : TDebugFrame);
That way, the TDebugFrm has no dependancies of its own (Except than on the TDebugFrame class). Any and all unit that requires to show the debug form can do so without risking to add too many dependancies either.
There are many other exemple... I bet it could fill a book of its own. Designing a clean class hierarchy in a time efficient fashion is pretty hard to do and it comes with experience. Knowing the tools available to achieve it and how to use them is the 1st step to achieve it. But to answer your question... There is no 1-size-fit-all answer to your question, it's always to be taken on a case by case basis.
Similar Question: Delphi Enterprise: how can I apply the Visitor Pattern without circular references?
The solution presented by Uwe Raabe uses interfaces to resolve the circular dependency.
Modelmaker Code Explorer has a really nice wizard for listing all the uses, including cycles.
It requires that your project compiles.
I agree with the other posters that it is a design issue.
You should carefully look at your design, and remove unused units.
At DelphiLive'09, I did a session titled Smarter code with Databases and data aware controls which contains quite few tips on good design (not limited to DB apps).
--jeroen
I found a solution that doesn't need the use of Interfaces but may not resolve every issues of the circular reference.
I have two classes in two units: TMap and TTile.
TMap contains a map and display it using isometric tiles (TTile).
I wanted to have a pointer in TTile to point back on the map. Map is a class property of TTile.
Class Var FoMap: TObject;
Normaly, you will need to declare each corresponding unit in the other unit... and get the circular reference.
Here, how I get around it.
In TTile, I declare map to be a TObject and move Map unit in the Uses clause of the Implementation section.
That way I can use map but need to cast it each time to TMap to access its properties.
Can I do better? If I could use a getter function to type cast it. But I will need to move Uses Map in the Interface section.... So, back to square one.
In the Implementation section, I did declare a getter function that is not part of my class. A Simple function.
Implementation
Uses Map;
Function Map: TMap;
Begin
Result := TMap(TTile.Map);
End;
Cool, I thought. Now, every time I need to call a property of my Map, I just use Map.MyProperty.
Ouch! Did compile! :) Did not work the expected way. The compiler use the Map property of TTile and not my function.
So, I rename my function to aMap. But my Muse spoke to me. NOOOOO! Rename the Class Property to aMap... Now I can use Map the way I intented it.
Map.Size; This call my little function, who typecast aMap as TMap;
Patrick Forest
I gave a previous answer but after some thinking and scratching I found a better way to solve the circular reference problem. Here my first unit who need a pointer on an object TB define in unit B.
unit Unit1;
interface
uses
Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms,
Dialogs, b, StdCtrls;
type
TForm1 = class(TForm)
Button1: TButton;
procedure Button1Click(Sender: TObject);
private
{ Private declarations }
public
{ Public declarations }
FoB: TB;
end;
var
Form1: TForm1;
implementation
{$R *.dfm}
procedure TForm1.Button1Click(Sender: TObject);
begin
FoB := TB.Create(Self);
showmessage(FoB.owner.name);
end;
end.
Here the code of the Unit B where TB has a pointer on TForm1.
unit B;
interface
Uses
dialogs, Forms;
type
TForm1 = class(TForm);
TB = class
private
FaOwner: TForm1;
public
constructor Create(aOwner: TForm);
property owner: TForm1 read FaOwner;
end;
implementation
uses unit1;
Constructor TB.create(aOwner: TForm);
Begin
FaOwner := TForm1(aOwner);
FaOwner.Left := 500;
End;//Constructor
end.
And here why it compiles. First Unit B declare the use of Unit1 in the implementation section. Resolving immediately the circular reference unit between Unit1 et Unit B.
But to allow Delphi to compile, I need to give him something to chew on the declaration of FaOwner: TForm1. So, I add stub class name TForm1 who match the declaration of TForm1 in Unit1.
Next, when come the time to call the constructor, TForm1 is able to pass itself has the parameter. In the constructor code, I need to typecast the aOwner parameter to Unit1.TForm1. And voilà, FaOwner his set to point on my form.
Now, if the class TB need to use FaOwner internally, I don't need to typecast it every time
to Unit1.TForm1 because both declaration are the same. Note that you could set the declaration of to constructor to
Constructor TB.create(aOwner: TForm1);
but when TForm1 will call the constructor and pass itself has a parameter, you will need to typecast it has b.TForm1. Otherwise Delphi will throw an error telling that both TForm1 are not compatible. So each time you call the TB.constructor you will need to typecast to the appropriate TForm1. The first solution, using a common ancestor, his better. Write the typecast once and forget it.
After I posted it, I realized that I made a mistake telling that both TForm1 were identical. They are not Unit1.TForm1 has components and methods that are unknown to B.TForm1. Has long TB doesn't need to use them or just need to use the commonality given by TForm you're okay. If you need to call something particular to UNit1.TForm1 from TB, you will need to typecast it to Unit1.TForm1.
I try it and test it with Delphi 2010 and it compiled and worked.
Hope it will help and spare you some headache.
I have two units unitA and unitB.
Class TFoo is declared in unitB.
Is it allways safe to call B.Free in finalization of unitA?
How does it depend on in which order unitA and unitB are in dpr?
Can I be sure that unitB exists when unitA finalization is executed?
unit unitB;
interface
type
TFoo = class
// code...
end;
// code....
end;
unit unitA;
// code..
implementation
uses
unitB;
var
A: TStringList;
B: UnitB.TFoo;
initialization
A:= TStringList.Create;
B:= UnitB.TFoo.Create;
finalization
A.Free;
B.Free; // Is it safe to call?
end.
Yes, you should be fine since B is created in Unit A. The rule is that the Initialization sections are called based on the order they are in the DPR, unless one of the units references another unit. In that case, the referenced unit is initialized first. Finalization is in the reverse order.
In your case Unit B does not have an initialization section, so it is a moot point. It will however use the TFoo definition in Unit B when the Unit A initialization section is executed.
Another word of warning about Initialization and Finalization sections - they happen outside of the global exception handler. Any exception that occurs there just terminates the application. So tracking down and debugging those exceptions can be a pain in large programs. You might consider using your own exception logging in there, just to be sure.
NO. You can try, you can hope but there is no guarantee in order of calling initialization and finalization. See qc72245, qc56034 and many more.
UPDATE:
finalization section is executed in reverse order than initialization. Your example is safe, you don't have dependency on calling initialization sections between units
Delphi can mix calling units (point 1 is still valid, both initialization and finalization sections are swapped)
Example:
unitA // no dependency on unitB
var SomeController;
initialization
SomeController := TSomeController.Create;
finalization
SomeController.Free;
unitB
uses
unitA;
initialization
SomeController.AddComponent(UnitBClass);
finalization
SomeController.RemoveComponent(UnitBClass);
Common (correct) order (99.99%) of calling:
unitA.initialization
unitB.initialization
run...
unitB.finalization
unitA.finalization
But sometimes can Delphi compile file wrong:
unitB.initialization - AV here
unitA.initialization
run...
unitA.finalization
unitB.finalization - and here too
Little offtopic story:
We have quite big project, with Type1 in Unit1, Type2 = class(Type1) in Unit2. Files are ordered in project.dpr and after years and adding Unit200 (no dependency with unit1/2) Delphi starts compiling project with Unit2.Initialization before Unit1.Initialization. Only safe solution is calling your own Init functions from initialization section.
As far as I understand it what you've got should be perfectly valid. A little awkward but valid.
But a better way might be to declare a variable in Unit B and have B initialize/finalize it.
Since initializations happen before any other code is called it will be initialize before it is made available to Unit A as long as it is declared in the uses clause of Unit A.
One other step you might want to consider is taking the unit variable of B one step further and have it as a function call for on demand loading, but that might also be dependant on your usage.
for example
unit unitB;
interface
type
TFoo = class
// code...
end;
// code....
function UnitVarB:TFoo;
implementation
var
gUnitVarB : TFoo;
function UnitVarB:TFoo
begin
if not assigned(gUnitVarB) then
gUnitVarB := TFoo.Create;
result := gUnitVarB;
end;
finalization
if assigned(gUnitVarB) then
gUnitVarB.free; //or FreeAndNil(gUnitVarB);
end;
unit unitA;
// code..
implementation
uses
unitB;
var
A: TStringList;
//code...
...UnitVarB....
//code...
initialization
A:= TStringList.Create;
finalization
A.Free;
end.
I seem to remember somewhere that unit initializations could be expensive in that if a unit that you no longer directly reference is still in your uses clause during a compile, the smart linker will not remove it because of the initialization section. While this may not sound that bad if every unit had an initialization section then most Delphi programs would be MUCH bigger than they already are.
I'm not saying don't use them but my rule of thumb is to use them sparingly.
Your initial code example breaks that rule. I thought I'd mention it.
Ryan
In the specific situation you are showing here, you will be alright. But it wouldn't take that much refactoring before it starts going wrong.
Delphi does a pretty good job making sure units stays in memory as long as they are needed. But it can only do so if it knows a unit is needed.
My classical example on the topic is a unit containing nothing but an objectlist
unit Unit1;
interface
uses
Contnrs;
var
FList : TObjectList;
implementation
initialization
FList := TObjectList.Create(True);
finalization
FList.Free;
end.
Unit1 is only explicitly dependant on Contnrs. Delphi will only ensure the Contnrs unit (and probably also "subdependant" units, though I'm not 100% sure) is still loaded in memory. If a TForm is added in the list, the Forms unit might be already finalized when FList.free is called it will crash when it tries to free the TForm it contains. Delphi has no way to know Unit1 requires the Forms unit. In this specific case, it will depend on the order units are declared in the dpr.
Yes, that is safe. You can simplify the compiler's job by declaring UnitB prior to UnitA in dpr file, but the compiler will resolve the references in any case.
In the spirit of full disclosure, I haven't developed in Delphi since 2005. However, I developed in Delphi exclusively starting with Delphi 1 in 1996, and was certified in Delphi 5 in 2001. That being said, my use of the finalization section was rare. The only time I would use it is if I needed to set up something special in the .dpr. That typically only occurred if I was doing custom component development, AND there were some dependencies that I needed to manage using other custom components I was developing.
For typical application development, I stayed away from the initialization/finalization section and just used design patterns like singletons, facades and factories to manage the creation and management of my classes. The built-in garbage collector was good enough for 98.5% of my projects.
To answer your question, you need to set up a dependency on TFoo in your UnitA code, and, as Ryan suggested, make sure it's assigned prior to destruction. That being said, I encourage you to make sure that the use of the initialization/finalization section is necessary before you invest too much time with it.
Am separating my delphi code into interface and implementation units ie.
EmployeeIntf.pas looks like this
type
// forward declaration
TScheduleList = class;
TDeparment = class;
TEmployee = class(BDObject)
....
function GetSchedules: TScheduleList;
function GetDepartment: TDepartment;
end;
TEmployeeList = class(DBList)
....
end;
TEmployeeDM = class(BDDBobject)
...
end;
Then i have the two units ScheduleIntf.pas & DepartmentIntf.pas which declare the TScheduleList class and TDepartment class.
Then in my main unit which combines all the units looks like this,
Unit BusinessDomain
Interface
uses
classes
{$I Interface\EmployeeIntf.pas}
{$I Interface\DepartmentIntf.pas}
{$I Interface\ScheduleIntf.pas}
Implementation
uses
SysUtils
{$I Implementation\EmployeeImpl.pas}
{$I Implementation\DepartmentImpl.pas}
{$I Implementation\ScheduleImpl.pas}
Initialization
finalization
end.
When i compile this the compiler throws an error;
*Type TScheduleList is not yet completely defined*
How can i have this classes separate in each unit file (.pas) and then do forward declarations without the compiler throwing this error?
The class themselvs are huge and i would prefer to separate them this way.
Gath
My first advice: Skip this $Include thing altogether. As Uwe wrote find a more Delphi-like solution.
If you really want to stay with the $Include style: The error you quote occurs because forward declarations don't work across "type" blocks. You forward declare TScheduleList in one block but define it in a different block. To cure this omit the "type" keyword in your *Intf.pas's and insert it in BusinessDomain.pas before the includes.
I'm afraid, there is no possibility to split a class declaration into multiple files. If the classes are that large, you should consider a redesign.
Another alternative are Interfaces:
type
IEmployee = interface
{ public properties and methods of an employee }
...
end;
type
TEmployee = class(BDObject, IEmployee)
...
end;
The interface and class declaration can now reside in different files.
Ulrich is quite correct (+1) whilst you can manipulate your include files to work approx this way, it's not going to be a very good Dev experience for you.
Think of the $Include directive as a simple text replacement mechanism, the things that make your units, well...units is the scoping mechanisms (uses sections, type sections etc) they will be much more difficult to use in an include file, thats why include files are usually called xxx.inc and not xxxx.pas as they often will not stand up as a source file by themselves. This of course makes them very difficult in a dev environment as they are then effectively just text files not proper debuggable units.
Include files are one of those legacy pascal features which keep rolling forward. There was a point when we didn't have a uses clause, and it was the only way to manage multiple files (of course we all programmed using wordstar commands for code navigation... wait, they are still there too).
Today, the most common use of include files is to include a block of code which must be shared among multiple files and can't be just used from another unit. As Mason pointed out in another comment, that would be the IFDEF-DEFINE blocks for determining things like what compiler options should be turned on, and what defines should be enabled project wide. We are no longer bound by the 64k limit on a source file.
Some other points to consider. Most of the tools for searching your source may not navigate into your include files. Using something as simple as a text search to find that text message that keeps popping up might be difficult. You would be much better served by not putting any code in them at all. When translating a map file to code, I believe your line numbers specified in the map file would be the total file if the include file was merged in place. If you use an automated tool such as MadExcept the error line reported might not be the actual location.
My suggestion would be to use interfaces as Uwe suggested. They are not just for COM, and can solve your desire to separate the "interface" from the "implementation".
Maybe my previous comment was a little presumptuous ... Reading your question again I think you may have misunderstood how to use units and in particular the "uses" directive.
You can declare individual classes both interface and implementation in a single unit file:
unit EmployeeDBCLassesU
uses system, DB, Blah, blah; // Units needed by this unit
interface
type
TEmployeeList = class(DBList)
Procedure DoSomething;
end;
TEmployeeDM = class(BDDBobject)
Procedure DoSomething;
end;
implementation
{TEmployeeList}
Procedure TEmployeeList.DoSomething;
begin
...
end;
{TEmployeeDM }
Procedure TEmployeeDM.DoSomething;
begin
...
end;
Then later to use them elsewehere:
Unit BusinessDomain
interface
uses EmployeeDBCLassesU; // MY units needed by this unit
.
.
.
This brings all the class definition in to BusinessDomain
and you can then do
TBusinessDomain = class(BDDBobject)
EmployeeList: TEmployeeList;
EmployeeDM: TEmployeeDM;
.
.
.;
end;
Hope this helps more as you will gain so much from the correct approach - you will realise this especially when navigating units for editing and Debugging.
If you really like to separate interface and implementation, have a look at Modula2. This is also a pascal like application, but it uses two files for each "unit". One for the interface and one for the implementation.
Another solution, is to split the files or class definitions, and write a custom preprocessor that links these (text wise) together. You then have something like:
unit BusinessDomain
interface
uses
classes;
type
Employment = class from Interface\EmployeeIntf.pas;
Department = class from Interface\DepartmentIntf.pas;
Schedule = class from Interface\ScheduleIntf.pas;
implementation
uses
SysUtils;
external define
Employment = class from Implementation\EmployeeImpl.pas;
Department = class from Implementation\DepartmentImpl.pas;
Schedule = class from Implementation\ScheduleImpl.pas;
end;
end.
With Delphi 2009 you can issue commands before and after the build phase. So technically this is possible.
I have a problem with maintenance on an old Delphi program (D7). A lot of the program logic is in the DPR file (this is not a windowed program), with some units providing things like access to the database. We need to get some debug out of the DB unit, but the debug functionality is in the DPR. We can't easily strip the debug functionality out, because it uses stuff that's unique to the DPR, like its main pipe. Separating it out would be like trying to tease apart spaghetti and meatball sauce.
So how do we call a function that's declared at the DPR scope from a subordinate used unit? What's the equivalent of the :: operator in C++ ?
Please don't tell me to redesign the app. I'd love to, but we won't be given the necessary time. Plus if we redesigned this puppy, it wouldn't be in Delphi.
You can declare a method variable in the unit that matches the signature of the function in the DPR. At the very beginning of the program you set the method variable to the function. Inside the unit you call the method variable.
Example:
(DPR)
uses
Unit1;
function DoSomething(Par: Integer): Integer;
begin
...
end;
...
begin
DoSomethingVar := DoSomething;
...
end;
(unit)
unit Unit1;
interface
...
var
DoSomethingVar: function(Par1: Integer): Integer;
...
implementation
...
SomeResult := DoSomethingVar(SomeParameter);
...
You can't. The unit hierarchy is rigid.
There are two possible options:
pull out the relevant parts of the .dpr to a new unit. Keep in mind that moving uses to the implementation can break import cycles. The createform* stuff probably isn't safe to move, that would probably upset the project manager.
or define a few callback functions (function,method types, like functionpointer in C), and move code out of the relevant unit initialization to a procedure that you call from the .dpr if necessary.
I don't know how to use functions from .dpr in other units, but if you have to change code simply change .dpr to normal unit and then use it's functions/routines in new .dpr and in others units.
.dpr is the most fundmental pascal project file.
We can use any unit files in the project, and so, you can use
the functions/procedures in the units.
If necessary, you can prefix the unit name for accessing the
function/procedure.
If the function/procedure belongs to specific class, you need
to create an instance to access the function/procedure because
it's a method.
Anyway, Delphi uses object pascal as its core, you can access
any necessary method/procedure/function/properties with legal
pascal concepts and object pascal concepts.
No matter which file you need to call it, and the only one except
is the decalaration file for some external library.