You won't be able to browse them in such case.white wrote:Perhaps you can present these folders as virtual files and solve it that way?
Might be solved by implementing FsExecuteFile, changing RemoteName to new path and return FS_EXEC_SYMLINK?MVV wrote:You won't be able to browse them in such case.white wrote:Perhaps you can present these folders as virtual files and solve it that way?
Another approach that might work:
Include a virtual file "copy this folder" in each folder. Don't do anything with this file when copied (FsGetFile), but copy the folder when executed (FsExecuteFile).
Search will not work with virtual files anyway...
No, I don't know if it works. Maybe not if I read this.MVV wrote:Have you tried to return FS_EXEC_SYMLINK?
I don't knowMVV wrote:How '..' will work for redirected folder?
Correct.MVV wrote:Search will not work with virtual files anyway...
There are functions in WCX API that pass callbacks. Some of them just pass function pointers:
Code: Select all
PkSetCryptCallback(tPkCryptProc pPkCryptProc,int CryptoNr,int Flags)
But some pass function pointer and some data pointer:
Code: Select all
SetChangeVolProc(HANDLE hArcData, tChangeVolProc pChangeVolProc1)
So does TC pass the same callback pointer for all hArcData values or there may be different callbacks for different archives? I expect that first case is correct because second one looks weird (it implies runtime code generation since there will be no way for TC to detect for which plugin/archive callback is called).
The only case when adding Unicode support is just straightforward as you say is when all plugin code uses TCHAR and Windows API for working with strings, and no CRT or STL where ANSI and Unicode require completely different functions and classes. But I don't think that most plugins work like that:)
- Site Admin
- Posts: 38017
- Joined: 2003-02-04, 09:46 UTC
- Location: Switzerland