When Delphi was busy compiling the "Forms" unit (somewhere in Scotts
Valley, California) it had to compile the "Controls" unit and everything
else relating to it. That was a lot of work that, if possible, Delphi
would prefer not to have to do all over again.
What Delphi wants to determine is the =minimal= number of ".PAS" files
that it must read in order to "understand" what your Delphi program is
saying. If you refer to a constant ("crXxxxx"...) Delphi wants to know
where to find it. It doesn't want to have to go chasing for it --
"lessee, we use Forms, and Forms uses X, Y, and Z, so maybe it's in X,
Y, or Z... or maybe it's in one of the units that X, Y, or Z uses..."
Pretty soon, you've got Delphi reading the source-code to the whole
<$%%@%!!> world trying to find a definition for "crXxxxx!" :->
So Delphi obliges -you- to tell it where to find that definition, in a
"Uses" clause occurring either in the interface part or the
implementation part (and there's a subtle difference between the two).
Pragmatically speaking, this is not only more efficient and more
practical -- it is also more reliable. It's better that you know
exactly what the compiler's doing ... what it's looking at, where it got
that definition for "crXxxxx" ... than to allow the compiler to "try to
be helpful."
Computers can't be "helpful" to humans. There was once an attempt by
IBM to produce a compiler that would "automatically fix" errors in a
program. The (probably apocryphal...) story goes that, as a final test,
IBM fed this compiler a copy of Abraham Lincoln's "Gettysburg Address,"
and it compiled with no errors.
Hmmm....
Quote
>Pierre Gemis wrote:
> [...]
> I know the crXxxxx identifiers are defined in the Controls unit, so I
> added it in the 'uses' clause and everything went Ok.
> However, the unit Forms was already in the same 'uses' clause, and I
> checked that Forms in turn 'uses' Controls...
> So why must I explicitely specify it in *my* 'uses' clause?
> Not really a problem, just curiosity...
------------------------------------------------------------------
Sundial Services :: Scottsdale, AZ (USA) :: (480) 946-8259
mailto:i...@sundialservices.com (PGP public key available.)
Quote
> Fast(!), automatic table-repair with two clicks of the mouse!
> ChimneySweep(R): "Click click, it's fixed!" {tm}
> http://www.sundialservices.com/products/chimneysweep