其实也不算是起因，只算是诱发今天这篇文章的起因吧。一朋友问到一个问题，已经引用了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的控件，如下图：

 再看看另一段代码：

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