WCX and DetectStrings

[baronPlug]

unlike list and content plugins, WCX don't seem to be using DetectStrings to tell what kind of files they handle. Is defaultextension the only way to go?

[MVV]

There is a special CanYouHandleThisFileW function in WCX API that TC calls in order to know if plugin supports a file that is being opened by Ctrl+PgDn (extension doesn't matter in such case).
If plugin doesn't have this function, it only can open archives directly associated with it by extension on Configuration - Plugins settings page.
Regardless of CanYouHandleThisFileW function, you can associate any number of extensions with every plugin (though only one extension may be associated with plugin during its installation - the one from defaultextension parameter).

[baronPlug]

thanks

from the documentation I see that the archive contents are read flat (without a notion of subfolder) using ReadHeader. If a plugin deals with subfolders, what is the recommended enumeration order? Depth first?
is there any C++ code sample that handles archives with subfolders?

[milo1012]

from the documentation I see that the archive contents are read flat (without a notion of subfolder) using ReadHeader. If a plugin deals with subfolders, what is the recommended enumeration order? Depth first?

I don't think there is a recommendation. TC must fill some kind of list or map data structure anyway, so I guess that some sort of binary (or linked list) sorting would take place anyway, no matter how you'd report the archive entries.
I did some basic benchmark with this and archives with a lot of files (> 50k) and didn't find any difference in terms of speed when trying to alter the report order.

BTW, it doesn't matter if you report each sub-dir manually or completely skip it.
So if you have an archive with sub-dirs in it, reporting

Code: Select all

dir1/
dir1/dir2
dir1/dir2/dir3/
dir1/dir2/dir3/file1.txt
...

or just reporting the individual file(s)

Code: Select all

dir1/dir2/dir3/file1.txt
...

will make no difference to TC and the (virtual) navigation in the archive.
The only thing missing for the latter type would be the individual dir timestamp and attributes.

As for a code snippet, I don't think there is a standalone sample, but there are several C/C++ based plug-ins with source available, f.e.
http://totalcmd.net/plugring/iso.html
http://totalcmd.net/plugring/7zip_plugin.html
http://totalcmd.net/plugring/wcxmsc.html

[baronPlug]

understood, thanks

one last thing: there is a capability PK_CAPS_SEARCHTEXT, but there is no interface just to search for text. All you can do is extract the whole file and search its contents. Am I missing something?

[milo1012]

there is a capability PK_CAPS_SEARCHTEXT, but there is no interface just to search for text. All you can do is extract the whole file and search its contents. Am I missing something?

[quote=""wcx interface help"]if PK_CAPS_SEARCHTEXT is returned, Total Commander will search for text inside files packed with this plugin. This may not be a good idea for certain plugins like the diskdir plugin, where file contents may not be available.[/quote]
Additionally, this is not a good idea for archive formats that use some sort of "solid" compression, e.g.
http://totalcmd.net/plugring/totalsqx.html
http://totalcmd.net/plugring/ZPAQ.html
(though I enabled partial support for it in the latest plugin version)
or the standalone 7-zip plugins,
because for such archive formats, extracting individual files is very/extremely slow, since there is no way to optimize the order of decompression requests through the current wcx interface.
Therefore, for such formats, Christian recommends to just collect all files in ProcessFile() and not extract anything yet, but finally extracting the collected files in CloseArchive(), which works quite well, but prevents text search, because:

the flag is just a hint that TC will try to:
-search archive content for text in the main search function (Find files)
-compare archive's file content in the Synchronize dirs function
But if enabled, TC requests each file to be extracted to the SAME temporary file in the user's temp directory (i.e. c:\Users\USERNAME\AppData\Local\Temp\) and reads it directly after the call to ProcessFile(). But this doesn't work when you just collected the files in ProcessFile(), so TC wouldn't find anything in the temp file.