DLLCALL问题请教

785953306

Declare Function FindFirstFile Lib "kernel32" Alias "FindFirstFileA" (ByVal lpFileName As String, lpFindFileData As WIN32_FIND_DATA) As Long
说明
根据文件名查找文件
返回值
Long，如执行成功，返回一个搜索句柄。如果出错，返回一个INVALID_HANDLE_VALUE常数，一旦不再需要，应该用FindClose函数关闭这个句柄
参数表
参数 类型及说明
lpFileName String，欲搜索的文件名。可包含通配符，并可包含一个路径或相对路径名
lpFindFileData WIN32_FIND_DATA，这个结构用于装载与找到的文件有关的信息。该结构可用于后续的搜索
注解
由这个函数返回的句柄可以作为一个参数用于FindNextFile函数。这样一来，就可以方便的枚举出与lpFileName参数指定的文件名相符的所有文件
请大神给写成TC的例子越详细越好

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

sam7894604

这几个API不难,自己至少写一半出来吧?

785953306

sam7894604 发表于 2015-9-24 13:27
这几个API不难,自己至少写一半出来吧?

能否给写个例子谢谢

785953306

sam7894604 发表于 2015-9-24 13:27
这几个API不难,自己至少写一半出来吧?

和没说一样

luqinlong

没看懂楼主想表达什么，只要符合tc里的变量类型任何api都可以调用啊

mjg2009

直接作汇编插件调用API比calldll强多了，不过我发现目前的汇编插件少了几个在本进程操作函数，一，申请内存，二，读取内存，三，取变量指针，四，写入内存。