| Declare Function GetFullPathName& Lib "kernel32" Alias "GetFullPathNameA" (ByVal lpFileName As String, ByVal nBufferLength As Long, ByVal lpBuffer As String, lpFilePart As Long) |
| 说明 |
| 获取指定文件的完整路径名 |
| 返回值 |
| Long，装载到lpBuffer中的字符数量（排除空中止字符）。如缓冲区的长度不足以容下完整的路径，则返回值就是要求的缓冲区大小。零表示失败。会设置GetLastError |
| 参数表 |
| 参数 | 类型及说明 |
| lpFileName | String，指定文件名（长文件名或8.3格式的DOS文件名） |
| nBufferLength | Long，lpBuffer字串的长度 |
| lpBuffer | String，指定一个预先定义好的字串，用于装载目标文件的驱动器及路径名称。如存在长文件名，那么这个参数保存的就肯定是长文件名 |
| lpFilePart | Long，指定一个长整数变量，用于装载文件名起始的地方。参考注解 |
| 注解 |
lpFilePart参数在vb里很难使用。它的问题在于：尽管windows在这个Long值中装载lpBuffer字串中的地址，用它表示路径信息文件名部分的起始处。但非常不幸，由vb创建的、传递给api的ANSI字串缓冲区也会使用这个地址。等这个函数返回的时候，vb已将返回的（lpBuffer）字串复制回它的内部Unicode字串缓冲区，所以lpFilePart地址已没有任何意义。因此，我们面临两种选择。首先，可以简单的不使用lpFilePart信息（忽略windows装载在参数中的值）。其次，可以将lpBuffer参数变成一个字节数组（lpFilePart As Byte——将数组的第一个元素作为参数传递） |
| 其他 |
| 在vb的api文本查看器中复制的声明为：Declare Function GetFullPathName Lib "kernel32" Alias "GetFullPathNameA" (ByVal lpFileName As String, ByVal nBufferLength As Long, ByVal lpBuffer As String, ByVal lpFilePart As String) As Long |
，只要符合tc里的变量类型任何api都可以调用啊