uses after interface / implement section?

[inetd]

What is the difference between using a unit after interface section and implementation section?
When should I place a uses statement after interface and after implementation?

Ex:

unit MyUnit;

interface

uses
Windows, Messages, SysUtils, Forms,
MyUsesUnit; // uses here?

....
....
....
implementation

uses MyUsesUnit; // or, uses here?

 

[shuesty]

Now I'm not sure about the possible speed difference between the two different sections but this is what I have gathered.

The difference between the two lay in the procedure/function/property/variable declarations. You need to create the reference to the needed classes before you are able to use the data type in your declarations. So before you create a global variable that is a TDateTime, you need to add the reference above it.

The two different uses sections allow you to have Object A use Object B and Object B use Object A. If you place both references into the first uses section the compiler will complain about cyclic referencing. To prevent any chance of cyclic referencing I would suggest referencing all of your own created components in the uses section after the implementation begins.
The one exception to the rule is if you create a global variable and define it as one of your components. In that case the reference to the component must be placed in the top uses section.



Shuesty

 

[BobbaFet]

The first uses is for libraries of functions and procedures, the second one for units the form uses so say for example you have got a unit1 and unit2 in your unit1 and are using for example QDialogs then it would look like this:

unit Unit1;

interface

uses
Windows, Messages, SysUtils, Forms, QDialogs;

....
....
....
implementation

uses Unit1, Unit2;

This will cause you to be able to access functions procedures and objects in unit2.

for example

procedure TForm1.Button1Click(Sender: TObject);
begin
if Form2.OpenDialog1.Execute then
Edit1.Text := Form2.OpenDialog1.FileName;
end;

So basically, the first uses is for procedural units and the second one for form units.

I hope this helps,

BobbaFet

Everyone has a right to my opinion.
E-mail me at caswegkamp@hotmail.com

http://cwcon.50megs.com/

 

[Stretchwickster]

I make the following simple distinction when adding units to the interface and implementation uses lists:

If the unit is required for the interface (i.e. class, method and variable declarations etc.) I add the unit to the former uses list.

If the unit is required only for the implementation of the class and/or methods then I add it to the latter uses list.

This particularly applies when I get an "Undeclared Identifier" compilation error. I see whether the highlighted line is in the interface/implementation section and then add the appropriate unit to whichever section contains the error.

-----------------------------------------------------------
Example
I get the following message:
[Error]Unit1.pas(37): Undeclared identifier: 'IntToStr'
I then double-click the error line and the offending line is highlighted in the Code Editor.
I notice the line is in the Implementation section, so I add "SysUtils" to the Implementation Uses list.
-----------------------------------------------------------

I also add a carriage return in each uses list between Delphi units and my own units - this is something I choose to do so that I can clearly see dependencies to Delphi units and my own.

Hope this helps!

Clive
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"To err is human, but to really foul things up you need a computer."
Paul Ehrlich
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
To get the best answers from this forum see: faq102-5096

 

[DelphiAaron]

When units reference each other directly or indirectly, the units are said to be mutually dependent. Mutual dependencies are allowed as long as there are no circular paths connecting the uses clause of one interface section to the uses clause of another. In other words, starting from the interface section of a unit, it must never be possible to return to that unit by following references through interface sections of other units. For a pattern of mutual dependencies to be valid, each circular reference path must lead through the uses clause of at least one implementation section.

In the simplest case of two mutually dependent units, this means that the units cannot list each other in their interface uses clauses. So the following example leads to a compilation error:

unit Unit1;

interface
uses Unit2;
...

unit Unit2;

interface
uses Unit1;
...

However, the two units can legally reference each other if one of the references is moved to the implementation section:

unit Unit1;

interface
uses Unit2;
...

unit Unit2;

interface
...
implementation
uses Unit1;
...

To reduce the chance of circular references, it’s a good idea to list units in the implementation uses clause whenever possible. Only when identifiers from another unit are used in the interface section is it necessary to list that unit in the interface uses clause.

Aaron Taylor
John Mutch Electronics

http://www.jme.com.au