Delphi7工程选项里自定义编译条件只有前面8个起作用,超过8个后,后面的就好像没定义一样,这是Delphi的限制吗?有没有什么方法扩大限制数量是8个之后的也能起作用?

解决方案 »

  1.   

    没听说过只有前8个条件起作用,你可以看Delphi的VCL源码,有些文件全都是条件编译。何止8个!
      

  2.   

    经常看到一些程序里面用到如:<BR>{$ifdef win16},{$ifdef win32}之类的信息,<BR>可是这些好像并没有定义,不知道在哪里可以找到这些条件编译的定义或者是说明具体讲述win16代表什么,WIN32代表什么,VER140。代表什么的? <BR><BR>{$IFDEF WIN32} -- 这可不是批注喔!<BR>对于Delphi来说﹐左右大括号之间的内容是批注﹐然而「{$」<BR>(左括号后紧接着货币符号)对于Compiler(编译器)而言并不是批注﹐<BR>而是写给Compiler看的特别指示。 
    <P><BR><STRONG>应用时机与场合<BR></STRONG>Delphi中有许许多多的Compiler Directives(编译器指令)﹐<BR>这些编译指令对于我们的程序发展有何影响呢? 它们又能帮我们什么忙呢?<BR>Compiler Directive 对程序开发的影响与助益, 可以从以下几个方向来讨论:<BR>?协助除错<BR>? 版本分类<BR>?程序的重用与管理<BR>? 设定统一的执行环境</P>
    <P><BR><STRONG>协助除错</STRONG><BR>稳健熟练的程序设计师经常会在开发应用系统的过程中﹐特别加入一些除错程序或者回馈验算的程序﹐这些除错程序对于软件品质的提升有极其正面的功能。然而开发完成的正式版本中如果不需要这些额外的程序的话﹐要想在一堆程序中找出哪些是除错用的程序并加以删除或设定为批注﹐不仅累人﹐而且容易出错﹐况且日后维护时这些除错程序还用得着。此时如果能够应用像是$IFDEF的Compiler Directives ﹐就可以轻易的指示Delphi要/不要将某一段程序编进执行文件中。同时﹐Compiler本身也提供了一些错误检查的开关﹐可以预先对程序中可能的问题提醒程序设计师注意﹐同样有助于撰写正确的程序。<BR><STRONG>版本分类<BR></STRONG>除了上述的除错版本/正式版本的分类之外﹐对于像是「试用版」「普及版」「专业版」的版本分类﹐也可以经由Compiler Directive的使用﹐为最后的产品设定不同的使用权限。其它诸如「中文版」「日文版」「国际标准版」等全球版本管理方面﹐同样也可以视需要指示Delphi特别连结哪些资源档或者是采用哪些适当的程序。以上的两则例子中﹐各版本间只需共享同一份程序代码即可。<BR>Delphi 1.0 与 Delphi 2.0有许多不同之处﹐组件资源文件(.DCR)即是其中一例﹐两者的档案格式并不兼容﹐在您读过本文之后﹐相信可以写出这样的程序﹐指示Delphi在不同的版本采用适当的资源文件以利于组件的安装。<BR>{$IFDEF WIN32} <BR>{$R XXX32.DCR} <BR>{$ELSE} <BR>{$R XXXX16.DCR} <BR>{$EDNIF}<BR><STRONG>程序的重用与管理<BR></STRONG>经过前文的讨论后﹐相信你已经不难看出Compiler Directives在程序管理上的应用价值。对于原始程序的重用与管理﹐也是Compiler Directives 使得上力的地方. 举例来说: Pascal-Style字符串是Delphi 1.0与 Delphi 2.0之间的明显差异﹐除了原先的短字符串之外﹐<BR>Delphi 2.0之后还多了更为方便使用的长字符串﹐同时﹐系统也额外提供了像是 Trim()这样的字符串处理函式。假如您有一个字符串处理单元必须要同时应用于Delphi 1.0 与2.0的项目时﹐编译指示器可以帮你的忙。<BR>此外﹐透过像是{$I xxxx} 这样的 Compiler Directives﹐我们也可以适当的含入某些程序, 同样有助于切割组合我们的程序或编译设定。设定一致的执行环境项目小组的成员间﹐必须有共同的环境设定﹐我很难预料一个小组成员间彼此有不同的{$B}{$H}{$X}设定﹐最后子系统在并入主程序时会发生什么事。<BR>此外, 当您写好一个组件或单元需要交予第三者使用时, 使用编译指示器也可以保证元件使用者与您有相同的编译环境。</P>
    <P><BR><STRONG>使用Compiler Directives</STRONG><BR>指令语法<BR>Compiler Directives从外表看起来与批注颇为类似, 与批注不同的是:<BR>Compiler Directives的语法格式都是以「{$」开始, 不空格紧接一个名<BR>称(或一个字母)表明给Compiler的特别指示, 再加上其它的开关或参数内容, <BR>最后以右大括号作为指令的结束, 例如:<BR>{$B+}<BR>{$R-}<BR>{$R MyCursor.res}<BR>同时, 就如同Pascal的变量名称与保留字一样, Compiler Directives也是不区分大小写的。<BR>从指令的语法格式来说Compiler Directives﹐可以进一步分类成以下三种格式:</P>
    <P><BR>?开关指令(Switch directives)<BR>这类指令都是单一字母以不空格的方式连接「+」或「-」符号; 或者是开关名称以一个空格后连接「ON」或「OFF」来表示作用/关闭某一个编译指示开关。例如:<BR>{$A+}<BR>{$ALIGN ON}<BR>开关型的编译指令不一定要分行写, 它们可以组合在同一个编译指示的批注符号之间,但必须以逗号连接, 而且中间不可以有空格, 例如:<BR>{$B+,H+,T-,J+}<BR><BR>光标停留在程序编辑器的任一位置时按下Ctrl+O O, 完整的Compiler Directives<BR>将会全部列于Unit的最上方。</P>
    <P><BR>?参数指令(Parameter directives) <BR>有些Compiler Directives需要在编译名称后面连接自定的参数(文件名称或指定的记忆体大小), 例如: {$R MyCursor.res}, 即在指示Delphi在编译连结时,含入「MyCursor.res」这个资源档。</P>
    <P><BR>?条件指令(Conditional directives) <BR>指示Compiler在编译的过程中, 按我们设定的条件, 选择性的采用/排除不同区域的程序代码。以下是一个条件编译的例子, 第一与第三列是写给Compiler看的,指示 Compiler在 __DEBUG这个条件名称完成定义的情况才编译ShowMessage()这列程序;<BR>反之, 如果 __DEBUG 当时没有定义的话, 这段程序几乎与批注无异, Compiler对它将视而不见。 <BR>{$IFDEF __DEBUG}<BR>ShowMessage(IntToStr(i));<BR>{$ENDIF}</P>
    <P><BR><STRONG>如何从IDE改变Compiler directives设定?</STRONG><BR>从Delphi的IDE程序整合发展环境, 我们很方便的就可以修改各个compiler directives的设定, 方法是:<BR>从Delphi IDE主选单: Project/Options/Compiler, 直接核选/取消各个CheckBox。值得注意的是, 改变一个项目的Compiler directives并不会影响其它的项目, 换言之,各个项目都保有自己一套编译指示。假如您希望其它的项目也采用相同一套的Compiler directives, 在上述Project Options对话盒的左下方有一个「Default」选项, 选取这个CheckBox之后, 虽然对于既有的项目没有作用, 但未来新的项目都将可以采用这组设定作为默认值。<BR>将Compiler directives写入程序<BR>透过Delphi的整合环境设定Compiler directives的确十分简便, 但是许多情况下我们仍然需要将Compiler directive直接加到程序中。至少有两个原因支持我们这么作:</P>
    <P><BR><STRONG>局部控制编译条件</STRONG><BR>在Project/Options/Compiler中所作的设定, 影响所及是整个项目, 如果某一段程序要特别使用不同的编译设定, 就必须直接将编译指示加到程序中。下列这段取自Online Help的程序范例, 即应用了{$I}编译指令局部控制在发生I/O错误时不要举发例外讯息, 这样, 我们就可以编译出一支在这段程序区域中不会产生I/O例外讯息的档案侦测函数。<BR>function FileExists(FileName: string): Boolean;<BR>var<BR>F: file;<BR>begin<BR>{$I-}<BR>AssignFile(F, FileName);<BR>FileMode := 0; ( Set file access to read only }<BR>Reset(F);<BR>CloseFile(F);<BR>{$I+}<BR>FileExists := (IOResult = 0) and (FileName &lt;&gt; '');<BR>end; { FileExists }</P>
    <P><BR><STRONG>程序的可移植性<BR></STRONG>我们都可能会用到其它公司或个人创作的unit或component, 也可能分享程序给其它人, 换句话说, 单元或程序可能会在不同的机器上编译, 直接将Compiler directives加入程序, 不仅可以免去程序使用前需要特别更改IDE的麻烦, 更重要的是解决了各个单元间要求不同编译环境的歧异。<BR>注意事项<BR>Compiler directives的作用与影响范围<BR>如同变量的可见范围与生命周期, 在我们使用 Compiler Directives 时也必须注意各个Compiler Directives 的作用范围.<BR>Compiler Directives的作用范围可分为以下两种:<BR>&nbsp;<EM>全域的</EM><BR>全域的Compiler Directives, 影响所及是整个项目; 我们稍早前提到经由Delphi IDE改变Compiler directives的方式就属于全域的设定。<BR><EM>&nbsp;区域的</EM><BR>而区域的Compiler Directives 影响所及只从Compiler Directives 改变的那一行开始, 直到该程序单元(Unit)的结束或另一个相同的Compiler Directives 为止,对其他的程序单元并没有影响。 <BR>也就是说, 如果在unit中特别加入Compiler directives, Compiler会优先采用区域的设定, 
      

  3.   

    经常看到一些程序里面用到如:<BR>{$ifdef win16},{$ifdef win32}之类的信息,<BR>可是这些好像并没有定义,不知道在哪里可以找到这些条件编译的定义或者是说明具体讲述win16代表什么,WIN32代表什么,VER140。代表什么的? <BR><BR>{$IFDEF WIN32} -- 这可不是批注喔!<BR>对于Delphi来说﹐左右大括号之间的内容是批注﹐然而「{$」<BR>(左括号后紧接着货币符号)对于Compiler(编译器)而言并不是批注﹐<BR>而是写给Compiler看的特别指示。 
    <P><BR><STRONG>应用时机与场合<BR></STRONG>Delphi中有许许多多的Compiler Directives(编译器指令)﹐<BR>这些编译指令对于我们的程序发展有何影响呢? 它们又能帮我们什么忙呢?<BR>Compiler Directive 对程序开发的影响与助益, 可以从以下几个方向来讨论:<BR>?协助除错<BR>? 版本分类<BR>?程序的重用与管理<BR>? 设定统一的执行环境</P>
    <P><BR><STRONG>协助除错</STRONG><BR>稳健熟练的程序设计师经常会在开发应用系统的过程中﹐特别加入一些除错程序或者回馈验算的程序﹐这些除错程序对于软件品质的提升有极其正面的功能。然而开发完成的正式版本中如果不需要这些额外的程序的话﹐要想在一堆程序中找出哪些是除错用的程序并加以删除或设定为批注﹐不仅累人﹐而且容易出错﹐况且日后维护时这些除错程序还用得着。此时如果能够应用像是$IFDEF的Compiler Directives ﹐就可以轻易的指示Delphi要/不要将某一段程序编进执行文件中。同时﹐Compiler本身也提供了一些错误检查的开关﹐可以预先对程序中可能的问题提醒程序设计师注意﹐同样有助于撰写正确的程序。<BR><STRONG>版本分类<BR></STRONG>除了上述的除错版本/正式版本的分类之外﹐对于像是「试用版」「普及版」「专业版」的版本分类﹐也可以经由Compiler Directive的使用﹐为最后的产品设定不同的使用权限。其它诸如「中文版」「日文版」「国际标准版」等全球版本管理方面﹐同样也可以视需要指示Delphi特别连结哪些资源档或者是采用哪些适当的程序。以上的两则例子中﹐各版本间只需共享同一份程序代码即可。<BR>Delphi 1.0 与 Delphi 2.0有许多不同之处﹐组件资源文件(.DCR)即是其中一例﹐两者的档案格式并不兼容﹐在您读过本文之后﹐相信可以写出这样的程序﹐指示Delphi在不同的版本采用适当的资源文件以利于组件的安装。<BR>{$IFDEF WIN32} <BR>{$R XXX32.DCR} <BR>{$ELSE} <BR>{$R XXXX16.DCR} <BR>{$EDNIF}<BR><STRONG>程序的重用与管理<BR></STRONG>经过前文的讨论后﹐相信你已经不难看出Compiler Directives在程序管理上的应用价值。对于原始程序的重用与管理﹐也是Compiler Directives 使得上力的地方. 举例来说: Pascal-Style字符串是Delphi 1.0与 Delphi 2.0之间的明显差异﹐除了原先的短字符串之外﹐<BR>Delphi 2.0之后还多了更为方便使用的长字符串﹐同时﹐系统也额外提供了像是 Trim()这样的字符串处理函式。假如您有一个字符串处理单元必须要同时应用于Delphi 1.0 与2.0的项目时﹐编译指示器可以帮你的忙。<BR>此外﹐透过像是{$I xxxx} 这样的 Compiler Directives﹐我们也可以适当的含入某些程序, 同样有助于切割组合我们的程序或编译设定。设定一致的执行环境项目小组的成员间﹐必须有共同的环境设定﹐我很难预料一个小组成员间彼此有不同的{$B}{$H}{$X}设定﹐最后子系统在并入主程序时会发生什么事。<BR>此外, 当您写好一个组件或单元需要交予第三者使用时, 使用编译指示器也可以保证元件使用者与您有相同的编译环境。</P>
    <P><BR><STRONG>使用Compiler Directives</STRONG><BR>指令语法<BR>Compiler Directives从外表看起来与批注颇为类似, 与批注不同的是:<BR>Compiler Directives的语法格式都是以「{$」开始, 不空格紧接一个名<BR>称(或一个字母)表明给Compiler的特别指示, 再加上其它的开关或参数内容, <BR>最后以右大括号作为指令的结束, 例如:<BR>{$B+}<BR>{$R-}<BR>{$R MyCursor.res}<BR>同时, 就如同Pascal的变量名称与保留字一样, Compiler Directives也是不区分大小写的。<BR>从指令的语法格式来说Compiler Directives﹐可以进一步分类成以下三种格式:</P>
    <P><BR>?开关指令(Switch directives)<BR>这类指令都是单一字母以不空格的方式连接「+」或「-」符号; 或者是开关名称以一个空格后连接「ON」或「OFF」来表示作用/关闭某一个编译指示开关。例如:<BR>{$A+}<BR>{$ALIGN ON}<BR>开关型的编译指令不一定要分行写, 它们可以组合在同一个编译指示的批注符号之间,但必须以逗号连接, 而且中间不可以有空格, 例如:<BR>{$B+,H+,T-,J+}<BR><BR>光标停留在程序编辑器的任一位置时按下Ctrl+O O, 完整的Compiler Directives<BR>将会全部列于Unit的最上方。</P>
    <P><BR>?参数指令(Parameter directives) <BR>有些Compiler Directives需要在编译名称后面连接自定的参数(文件名称或指定的记忆体大小), 例如: {$R MyCursor.res}, 即在指示Delphi在编译连结时,含入「MyCursor.res」这个资源档。</P>
    <P><BR>?条件指令(Conditional directives) <BR>指示Compiler在编译的过程中, 按我们设定的条件, 选择性的采用/排除不同区域的程序代码。以下是一个条件编译的例子, 第一与第三列是写给Compiler看的,指示 Compiler在 __DEBUG这个条件名称完成定义的情况才编译ShowMessage()这列程序;<BR>反之, 如果 __DEBUG 当时没有定义的话, 这段程序几乎与批注无异, Compiler对它将视而不见。 <BR>{$IFDEF __DEBUG}<BR>ShowMessage(IntToStr(i));<BR>{$ENDIF}</P>
    <P><BR><STRONG>如何从IDE改变Compiler directives设定?</STRONG><BR>从Delphi的IDE程序整合发展环境, 我们很方便的就可以修改各个compiler directives的设定, 方法是:<BR>从Delphi IDE主选单: Project/Options/Compiler, 直接核选/取消各个CheckBox。值得注意的是, 改变一个项目的Compiler directives并不会影响其它的项目, 换言之,各个项目都保有自己一套编译指示。假如您希望其它的项目也采用相同一套的Compiler directives, 在上述Project Options对话盒的左下方有一个「Default」选项, 选取这个CheckBox之后, 虽然对于既有的项目没有作用, 但未来新的项目都将可以采用这组设定作为默认值。<BR>将Compiler directives写入程序<BR>透过Delphi的整合环境设定Compiler directives的确十分简便, 但是许多情况下我们仍然需要将Compiler directive直接加到程序中。至少有两个原因支持我们这么作:</P>
    <P><BR><STRONG>局部控制编译条件</STRONG><BR>在Project/Options/Compiler中所作的设定, 影响所及是整个项目, 如果某一段程序要特别使用不同的编译设定, 就必须直接将编译指示加到程序中。下列这段取自Online Help的程序范例, 即应用了{$I}编译指令局部控制在发生I/O错误时不要举发例外讯息, 这样, 我们就可以编译出一支在这段程序区域中不会产生I/O例外讯息的档案侦测函数。<BR>function FileExists(FileName: string): Boolean;<BR>var<BR>F: file;<BR>begin<BR>{$I-}<BR>AssignFile(F, FileName);<BR>FileMode := 0; ( Set file access to read only }<BR>Reset(F);<BR>CloseFile(F);<BR>{$I+}<BR>FileExists := (IOResult = 0) and (FileName &lt;&gt; '');<BR>end; { FileExists }</P>
    <P><BR><STRONG>程序的可移植性<BR></STRONG>我们都可能会用到其它公司或个人创作的unit或component, 也可能分享程序给其它人, 换句话说, 单元或程序可能会在不同的机器上编译, 直接将Compiler directives加入程序, 不仅可以免去程序使用前需要特别更改IDE的麻烦, 更重要的是解决了各个单元间要求不同编译环境的歧异。<BR>注意事项<BR>Compiler directives的作用与影响范围<BR>如同变量的可见范围与生命周期, 在我们使用 Compiler Directives 时也必须注意各个Compiler Directives 的作用范围.<BR>Compiler Directives的作用范围可分为以下两种:<BR>&nbsp;<EM>全域的</EM><BR>全域的Compiler Directives, 影响所及是整个项目; 我们稍早前提到经由Delphi IDE改变Compiler directives的方式就属于全域的设定。<BR><EM>&nbsp;区域的</EM><BR>而区域的Compiler Directives 影响所及只从Compiler Directives 改变的那一行开始, 直到该程序单元(Unit)的结束或另一个相同的Compiler Directives 为止,对其他的程序单元并没有影响。 <BR>也就是说, 如果在unit中特别加入Compiler directives, Compiler会优先采用区域的设定, 
      

  4.   

    编译条件很多的话,可以将编译条件写到一个文本文件中,并保存为.inc文件
    在代码里使用
    {$I filename}或者
    {$INCLUDE filename}