在unit2
implementation
uses unit1;

解决方案 »

  1.   


    文本乃手工敲打的第二遍,第一遍直接在浏览器中写,由于超时失去Session而使心血付诸东流(感想同Kingron——对CSDN愤怒中……)单看寥寥分数实在不值,但念为诸兄留下值得参考之帖,遂鼓起勇气,重新来过!(《仙剑》:胜败乃兵家常事,大侠重新来过……)//--------------------------------------------------------------------------------1、单元引用的起效范围?uses进行外部单元引用表示本单元可以对所引用的外部单元接口声明的内容进行访问。interface下uses的单元,表示在本单元的任何位置(接口部分与实现部分)都可以引用“(被引用的外部单元的)接口声明内容”;implementation下的uses单元,表示只有本单元implementation关键字以下(实现部分)的代码才可以引用“(被引用的外部单元的)接口声明内容”;
    2、单元引用的一般规则是什么?如果本单元的接口部分使用了其它单元的声明内容,那么该引用声明(uses)需要添加在本单元的interface下;如果仅是本单元的实现代码用到了外部单元的声明内容,那么将该引用声明(uses)放在implementation下;
    3、什么是“循环编译”错误,为什么会有这样的编译错误指示?“循环编译”指在对程序进行编译的过程中,发现在两个或多个单元的“interface部分(注意:这里不包括implementation中引用的外部单元)”存在着单元相互引用的问题。如下例子(仅简单的示意):unit Unit1interfaceuses Unit2;//--------------------------------------------------------------------------------unit Unit2interfaceuses Unit3;//--------------------------------------------------------------------------------unit Unit3interfaceuses Unit1;
    那么,产生这个错误的原因是什么呢?这要从Delphi的模块原则及其编译方式说起,Delphi对单元编译的内容分为两部分——“接口部分”与“实现部分”。因为每个单元的代码在引用外部单元声明的内容时,能且只能引用(已经包含在uses中的)外部单元的接口部分的声明。因此,当要编译一个单元时,首先要对本单元使用的“外部单元”的接口部分进行编译(本句所说的“外部单元”包括interface部分与implementation部分声明的所有外部单元)。于是,产生了上面例子中的问题:在编译单元Unit1时(此时单元Unit1的接口部分及实现部分均还未完成编译),首先需要完成对单元Unit2接口声明部分的编译;而Unit2的接口部分又引用到了Unit3的接口声明,所以又先要完成对单元Unit3接口声明部分的编译;同理,要完成Unit3接口部分的编译又要先完成Unit1的接口部分的声明……(对照前面内容“此时单元Unit1的接口部分及实现部分均还未完成编译”,所以出现了编译错误提示!)这与C/C++中的include重复编译倒有些个神似!
    4、如何消除“循环编译”错误?消除“循环编译”错误的办法:首先,也是最根本的办法,就是从设计入手,确定个单元之间的关系,做到心中有数,而不是“哪里有洞补哪里”,理清关系才是根本解决之道!对于系统提供的单元(诸如:Classes、System、Forms等等),这些单元可以都直接放在interface下的uses中,而不用考虑其引用范围是否恰当及是否会产生“循环编译”错误!因为,这些系统预编译单元是不会引用到用户自己的单元的,也就不可能产生“循环编译”错误!不会产生“循环编译错误”,再把它们放在interface下的uses中,也可以省去了对引用范围是否恰当的顾虑了。
    其次,就是一些一般方法和补救措施。有上面2中的一般方法,另外还有一些补救措施!对于已经产生该错误的程序,可以由以下步骤来解决:A、直接将发生错误引用单元祛除或转移至implementation下的uses,看是否奏效;B、分析,如果本单元对外部单元的“量”(变量等)的引用可以转化为参数传递,则换成参数传递的函数等,然后再祛除或转移至该单元的引用声明;C、又如果,确实是一些相互引用的类型、类定义等内容,还可以提取出这些相互应用的内容,重新新建新的基础单元来包装这些内容,而在原来的单元中引用新的基础单元;
    (实际上,并不存在解决不了的单元互调现象。)*附注* TURBO PASCAL/Delphi编译器的高速编译是举世文明的,为了达到这样的效果,也同时增加了一些代码逻辑的要求。但是,它并不会影响多少灵活性,反而倒是易于对代码和设计模式进行规范,因此是绝对划得来的。相反的,C/C++为了保持历史的、全面的兼容性能,而被迫提供了许多复杂(甚至有一些可以认为是多余)的处理能力,而很大程度上降低了编译的效率。可以这样说,C/C++是以古老的文件(File)模式进行编译的,而TURBO PASCAL/DELPHI则是以单元(Unit)的模式进行编译的;TURBO PASCAL/DELPHI的编译模式要比C/C++的编译模式来得“文明”的多!还有许多的细节,如:C/C++中include多重嵌套文件中的宏MACRO在编译时仍然起效,而Delphi中的宏,如{$DEFINE},仅在本单元编译时起效,这些都无形中减轻了编译器的压力,加快了速度……最后,愿各位Delphi的同仁一起多加把劲,然后……
      

  2.   

    NO.1
      互相引用,二者不要都放到inferface的uses里,也不要都放到implementation的uses
    NO.2
      借助另一个Unit单元,推荐你用这种方法