Plugin interface descriptions for TC 7.5 (beta)

[ghisler(Author)]

Packer plugins:
https://plugins.ghisler.com/beta/wcx_ref2.20.zip

Lister plugins:
https://plugins.ghisler.com/beta/listplughelp2.0.zip

File system plugins:
https://plugins.ghisler.com/beta/fspluginhelp2.0.zip

Content plugins:
https://plugins.ghisler.com/beta/contentpluginhelp20.zip

Sample "fsplugin" to which the help files refer to:
https://plugins.ghisler.com/beta/fsplugin.zip

[tbeu]

About Unicode support: It is said in the interface description

Add the files cunicode.h and cunicode.cpp to your project.

However, cunicode.cpp includes fsplugin.h which is normally not used for WCX, WDX or WLX. So, should all plugin types use fsplugin.h?

In contentplugin.HLP -> contplug.h there is still the old version number in the comment

// Contents of file contplug.h version 1.5

[Lefteous]

There are two ways of creating Unicode plugins. The first is to add Unicode functions to an existing plugins.
The second is to use generic characters and compile an Ansi and a Unicode version of the plugin. If you can go this way you should do it.

[ghisler(Author)]

Indeed you are right - please remove the following definitions and functions for other plugin types:

#include "fsplugin.h"

extern tProgressProc ProgressProc;
extern tLogProc LogProc;
extern tRequestProc RequestProc;
extern tProgressProcW ProgressProcW;
extern tLogProcW LogProcW;
extern tRequestProcW RequestProcW;

ProgressProcT
LogProcT
RequestProcT

[nyam]

Happy to hear 'Unicode support'.

Thank you.

[nyam]

In listplugin.hlp, There're two ListGetPreviewBitmap' at 'listplug.h' topic.
I think that the later should be named 'ListGetPreviewBitmapW'.

[ghisler(Author)]

You are right, thanks!

[ND]

WCX Writer's Reference -> 5. Callbacks -> [face=courier]tPkCryptProc[/face]
vs.
[face=courier]wcxhead.h[/face] & [face=courier]wcxhead.pas[/face]

Unlike the other callback links, the [face=courier]tPkCryptProc[/face] goes to a function [face=courier]PkCryptProc()[/face] instead of the typedef.
This in itself is not a problem, but I found differences when compared with the source code.

In [face=courier]wcxhead.h[/face] the typedef [face=courier]tPkCryptProc[/face] has an additional [face=courier]int PluginNr[/face] as the first parameter:

Code: Select all

//wcxhead.h
typedef int (__stdcall *tPkCryptProc)(int PluginNr,int CryptoNr,int Mode,
             char* ArchiveName,char* Password,int maxlen);

In [face=courier]wcxhead.pas[/face] the type has a different name, but at least the parameters are the same as the help-file:

Code: Select all

{wcxhead.pas}
  TPkPluginCryptProc=function(CryptoNr:integer;mode:integer;ArchiveName,
    Password:pchar;maxlen:integer):integer; stdcall;

Except the name of one parameter is different in the help-file: [face=courier]CryptoNumber[/face] vs. [face=courier]CryptoNr[/face].

[ghisler(Author)]

Thanks, I have just corrected the C documentation. There is indeed no PluginNr parameter for packer plugins.

[ND]

Thanks, I have just corrected the C documentation. There is indeed no PluginNr parameter for packer plugins.

The Unicode typedef [face=courier]tPkCryptProcW[/face] still has the extra [face=courier]PluginNr[/face] parameter.

------------------------------------------

An additional thing I found is in the documentation of callback function [face=courier]PkCryptProc()[/face]: the return value mentions the constant [face=courier]FS_FILE_OK[/face] for "Success" which is not part of the documented Error codes (where directly the value "0" is given for this purpose). Since that constant is also missing from the source code files, I assume it's coming from the "fsplugin" sample?

------------------------------------------

Like with v2.12, I have made a conversion of the WCX Writer's Reference v2.20 documentation to CHM, which can be found here: http://geocities.com/kirnbie/wcx_knd/

[ghisler(Author)]

Yes, it's just 0.

[j]

It would be nice to mention that ft_stringw has to be used when returning Unicode strings in the "Unicode Support" section of the content plug-in help.

Thank you.

[ghisler(Author)]

OK, I will add the following explanation:

Note: You need to return the type ft_stringw instead of ft_string for Unicode content in ContentGetValueW. This allows you to return either ANSI or Unicode content.

[Summr]

Dear Christian!

I'd like to draw your attention that you use PChar for the parameters of the Ansi functions in fsplugin.pas, but PChar means PWideChar starting from Delphi 2009 so the types won't match. It would be better to use PAnsiChar there.

Best regards
Nyíri László from Hungary

[ghisler(Author)]

Sorry, I do not have Delphi 2009, so I didn't know about that. Isn't it a compiler switch?