• Delphi D10.X中Tpath引发的单元引用及代码编写的思考


    事件起因

    其实也不算是起因,只算是诱发今天这篇文章的起因吧。一朋友问到一个问题,已经引用了system.IOUtils单元,为什么还是会提示错误?

     大家都知道在FMX中,IO相关的都整合到System.IoUtils单元内,对应的文件路径也都在这个单元内,在跨平台的代码中,我们会经常使用到。出现这样的情况,如果不清楚是什么原因,会感觉很是“邪门”(用了朋友的话,版权不在我)
    (TPath怎么用?自己去找一下哈,本文不讲。)

    模拟重现

    新建一个空FMX项目,增加两个单元 system.IOUtils与 FMX.Objects的引用,随意在某个事件中写一行代码:Tpath.combine,会如下图:

     我们进行一下调整,把两个单元文件的引用改变一下顺序,结果如下图:

    神奇的一幕出现了,是不是不再提示错误。

    追源求解

    现在,我们来看看system.IOUtils与 FMX.Objects两个文件为什么会出现这样的情况。
    首选是分别打开两个源码文件,我们可以看到,在FMX.Objects里定义了一个以TPath命名的类,在system.IOUtils里有一个以TPath命名的记录。

     FMX.Objects文件里的TPath.

    system.IOUtils里的TPath.

    所以,当FMX.Objects引用在后面时,系统认可的是TPath类,这个类是没有Combine函数的,自然会提示有错误。
    到这里,相信大家也知道了解决办法(之一),调整单元引用的顺序,即可解决当前问题。
    可是,现在新的问题出现了,如果我们同时又需要使用TPath类里的Data属性(TPathData类型的数据),就会出现下图情况(我代码有省略没写全的哈,只为展现出现的情况):

     Tpath.Data提示错误了。回头再更换一下两个引用单元的顺序,会变为Tpath.Data可用,Tpath.combine不可用。
    所以需要引出第二种解决方式:在Tpath.combine前增加单元名:system.IOUtils。

    很多时候,我们多留意一下,会发现在Delphi的一些源码中,就使用的这种方式。
    我个人也推荐这种方式,有时候多写几个字,会有好处的。
    (引出一个话题,With do大家也不要乱用,为什么?这里先不说。别省那点敲代码的时间,懒是优点也是缺点)

    分析总结

    简单总结,解决方法有2种:

    • 将system.IOUtils的引用放到单元FMX.Objects后面;
    • 在TPath前增加单元名,如:system.IOUtils.TPath。推荐使用解决方法。

    为什么会出现同名?
    搜索一下path的控件,如下图:

     再看看另一段代码:

     请注意上图里的红框与黄底的内容。这是很常用的定义方式。
    好吧,今天先写这么多。多了也懒得看。

    好的代码像粥一样,都是用时间熬出来的
  • 相关阅读:
    js的同步与异步
    单体应用SSM
    Spring 事务管理简介
    Linux
    Docker
    spring Cloud Netflix
    平台即服务
    MySQL InnoDB 索引组织表 & 主键作用
    Innodb Double Write
    Laravel 5.6: Specified key was too long error
  • 原文地址:https://www.cnblogs.com/jijm123/p/14349866.html
Copyright © 2020-2023  润新知