首页
学习
活动
专区
工具
TVP
发布
精选内容/技术社群/优惠产品,尽在小程序
立即前往

防止在Delphi包中隐式导入单元

防止在 Delphi 包中隐式导入单元的方法是使用 {$IFDEF}{$IFNDEF} 预处理器指令来有条件地包含单元。这样可以确保只有在特定条件下才会导入特定单元。

例如,假设您有一个名为 MyPackage 的包,其中包含两个单元 Unit1Unit2。您可以使用以下代码来防止隐式导入 Unit2

代码语言:delphi
复制
{$IFDEF CONDITION}
uses
  Unit1;
{$ELSE}
uses
  Unit1, Unit2;
{$ENDIF}

在这个例子中,只有在 CONDITION 被定义时才会导入 Unit1。如果未定义 CONDITION,则会导入 Unit1Unit2

您可以根据需要设置不同的条件,以确保只有在特定条件下才会导入特定单元。这可以帮助您更好地控制包中的依赖关系,并确保您的代码更易于维护。

页面内容是否对你有帮助?
有帮助
没帮助

相关·内容

  • 软件测试--selenium脚本编写注意点(一)

    在通过python+selenium编写ui自动化脚本的时候,我遇到过很多需要注意的点,今天分享给大家一下。 一、睡眠时间 1、 强制等待时间 sleep() 必须导入time包后才可以使用,强制等待生效时间=页面跳转时间+sleep()设置休眠时间 强制等待时间使用语法:sleep(s) s表示时间,以秒为单位 例:sleep(2) 休眠2s 2、显示等待时间 WebDriverWait() 必须导入WebDriverWait包才可以使用,显示等待时间是针对单个元素生效的,当在规定时间内找到了对应元素,则执行下一步操作。 显示等待时间使用语法: WebDriverWait(x,y,z).until(lambda x:x.find_element_by_元素定位方法("对应元素方法的值")) x表示网页窗口对象 y表示总等待时间(s) z表示等待过程中,每隔多久查看一次元素,单位s ntil是固定格式,可以理解为直到元素定位到为止,lambda x:x是一个匿名函数构建的方法,这里不太好理解可以理解为固定格式lambda总体就是网页窗口对象,而后面的.find_element_by_....就是援用之前的定位方法 3、隐式等待时间 implicitly_wait() 智能等待时间,是针对全局的元素都生效,不需要导入包。当在规定时间内找到了对应元素,则执行下一步操作。 隐等待时间使用语法: 网页对象名.implicity_wait() from selenium import webdriver from time import sleep #导入强制等待时间的包 from selenium.webdriver.support.ui import WebDriverWait #导入显示等待时间的包 dr = webdriver.Firefox() dr.maximize_window() dr.implicitly_wait(5) #隐式时间等待,智能等待,针对于全局 dr.get("https://www.baidu.com") sleep(2) #休眠2s a = WebDriverWait(dr,10,2).until(lambda x:x.find_element_by_id("kw")) #显示等待时间,针对于单个元素进行时间的等待 a.send_keys("123") #总结:只针对一个元素进行时间的等待,要是找不到该元素则会一直消耗完所有的等待时间才进行下一步 二、定位alert弹出框 alert弹出框包含三种: alert 提醒对话框 confirm 确认对话框 prompt 要求用户输入,然后返回结果的对话框 1、定位方法 switch_to.alert:定位到alert/confirm/prompt text:返回alert/confirm/prompt 中的文字信息。 accept:点击确认按钮。 dismiss:点击取消按钮,如果有的话。 send_keys:输入值,这个alert\confirm 没有对话框就不能用了,不然会报错。 2、alert用法

    00

    Delphi中利用SEH屏蔽退出时的Runtime Error

    Delphi写的程序,如果在单元的finalization里出现了一些异常操作会导致退出时抛出Runtime Error ,规范的处理办法当然是解决这些异常,但是有些特殊的情况下,比如用了很多的第三方控件,实在没办法解决问题时,只有把他屏蔽掉,这样给客户的时候就不至于看到满天的Runtime Error 了。 做法其实很简单,就是在 END.之前手工调用Halt释放,并且将Halt抛出的错误屏蔽掉,这样做和正常的DELPHI释放过程没有任何区别,因为End.编译后其实就是一句话 Call Halt0,只是VCL自己没有屏蔽Halt0里抛出的错误,而是跳出个Runtime Error 来;   首先就是位置的问题,如果是EXE的话,直接在END.之前就行了,如果是Dll的话就麻烦点,需要挂上DllProc,当wReason = DLL_PROCESS_DETACH时处理。 然后就是如何屏蔽错误的问题了,第一个最容易想到的做法就是直接 Try  halt except end;   但是这样是不行的,因为try…except end捕获的错误都会放到System单元的_HandleOnException中处理,函数检查错误类型是否是DelphiException,如果不是就不处理,这个时候就会被DELPHI的顶层异常机制捕获,并抛出Runtime error,halt里抛出来的错误恰恰就是非DelphiException,代码如下:  procedure _HandleOnException; …   CMP [EAX].TExceptionRecord.ExceptionCode,cDelphiException   JE @@DelphiException   CLD   CALL _FpuInit   MOV EDX,ExceptClsProc   TEST EDX,EDX   JE @@exit    CALL EDX   TEST EAX,EAX   JNE @@common   JMP @@exit … End; 所以,需要借助SHE机制来处理这个问题,代码如下:   asm    //挂上SEH xor edx, edx    push ebp   push OFFSET @@safecode   push dword ptr fs:[edx]   mov fs:[edx],esp   //调用Halt0   call Halt0   jmp @@exit;   @@safecode:    //如果出现异常继续调用Halt0退出 call Halt0;   @@exit:  end; 这个做法的好处就是,不会对DELPHI正常释放过程产生影响,所有的释放操作都是和VCL一致的,只是不会把错误显示出来。 以下是完整代码: 一、EXE的情况,把代码放在工程文件 procedure Halt0; begin Halt; end; begin Application.Initialize; Application.CreateForm(TForm1, Form1); Application.Run; asm  xor edx, edx  push ebp  push OFFSET @@safecode   push dword ptr fs:[edx]  mov fs:[edx],esp   call Halt0  jmp @@exit;  @@safecode:   call Halt0;   @@exit: end; end.

    04

    Delphi 语言「建议收藏」

    自1995年Borland公司发布Delphi 1.0以来,Delphi受到很多开发者的亲睐,到1999年发布Delphi5,Delphi以其开发快捷、控件丰富、易于上手等优势吸引了众多的开发者,用户人数达到高潮,一度超越Visual Studio。可是好景不长,在推出Delphi7之后不久,Borland公司也走向衰败,最终被人收购,仅卖了区区7500万美元。 Borland公司倒闭的主要原因是公司财务出现困难,内部矛盾上升。但我认为深层次的原因是产品定价死板且价格过高,记得当时一套Delphi正版要卖68000人民币,而同期的Visual Studio仅卖一万多人民币。过高的定价导致很多人放弃使用正版用盗版。这可能是Borland公司财务困难的主要原因。 一、倒闭后的版本变迁 Borland公司倒闭后,先是到易博龙手中,再转到微软,最后到Embarcadero手中。Borland的最后版本是Delphi7。之后有Delphi2005到Delphi2010,这些版本基本不受Delphi开发者关注,因为D7就用得很好。Embarcadero推出DelphiXE,版本升得很快,目前已经到了XE10.2。并在XE5开始支持手机开发。引起一些Delphi的关注。 二、Delphi目前的用户人群 Borland公司倒闭后,导致很多Delphi爱好者信心产生动摇,加之Jave和.net兴起,许多开发者纷纷转向,放弃Delphi,Delphi用户群体急剧流失。经过若干年后,剩下的Delphi开发者估计只剩下三类人: 1、业余开发者,转向其他开发工具比较困难的人; 2、 Delphi死粉,这类人很少,程序员毕竟要吃饭,不会有人死抱着Delphi失业的,所谓死粉应该还是那些不愿意或有困难转向的人; 3、 手头有大量已有Delphi系统,无法全部重写,只能留在Delphi的人。 年轻的开发人员基本上不进入Delphi,大家都知道Delphi是一个没落的工具,学了也不好找工作,干脆不进来。所以,到目前,Delphi的开发者基本上是老司机。我曾去参加过一次Delphi XE的新版本发布会,参会的人基本上都在30岁以上,这还是好几年前。所以,Delphi可以说是后继无人。 老司机们的年龄最小估计也在35岁左右了,新人不进来,这些人将会在五年十年后淡出编程,大部分人到了这个年龄基本上想混个一官半职,脱离Coding的苦海。所以,Delphi命不长矣。 三、Delphi用户目前的困境 1、硬件及操作系统的升级让用户无法停留的D7上 大多数继续使用Delphi的人基本上仍在使用Delphi6或Delphi7的版本,后者人数较多。Delphi几经转手,继D7之后也出了一些版本,什么Delphi2005.net、2009、2010到现在有XE,XE都到十了。让老司机们无法继续留在D7的原因主要是操作系统及计算机硬件的升级,Delphi7之前的版本在XP 32位系统下运行很好,但到后面的Win7及64位系统就不灵了,加以对多核CPU的支持也没有。XP已经不被微软支持等。这样又迫使部分人离开Delphi,剩下的老司机考虑往XE上寻求升迁老的系统。 2、XE对Windows开发支持不好 从Delphi XE最新的版本取向来看,Embarcadero似乎更专注于移动开发,最新的版本还想走向Linux,而放弃对Windows的支持。D6和D7只专注于Windows上的开发,现在XE要同时支持Windows、Android、IOS和Linux,可谓战线拉得太长。对Windows的开发支持感觉越来越差。要知道现在主要用户是老司机,老司机走老路,EXE+DLL,他们要把老系统迁到新工具下,才能去继续按老方法使用Delphi的新功能,开发Android、IOS和Linux,但XE好象一到DLL就不行,这就不能解决老司机们的后顾之忧,老司机们的后顾之忧就是要把他们的那些旧坛坛罐罐搬到新的XE上面来,没有解决这个之前,他们不会心思去用XE的新功能。 另外,Delphi写Android、IOS和Linux不就是为老司机们准备的吗,新司机谁他娘的还用Delphi这破东西呢,何况Android、IOS和Linux下本身就有很多开发工具都是开源免费的,又正宗又原生态、又成熟又用者众,Delphi真是一点优势都没有,除了让那些只会Delphi又不愿离开Delphi的老司机用,还有谁用呢。 再说,用Delphi开发Android和IOS永远会落在别人屁股后面。因为Android是Google的,IOS是苹果的,这两家都有自己的开发工具,当Android和IOS升级时,人家自己系统立即支持新看到本,而Delphi还要等到Embarcadero是否

    02
    领券