Plugin interface descriptions for TC 7.55 (beta)

[ts4242]

2ghisler(Author)

All Plugin interface descriptions are use hlp format. Is it possible to provide them as chm? because Win 7 doesn't support the hlp format without a special download.

Of course i can convert them myself, but it is better to be available for all plugins page visitors.

[ghisler(Author)]

I will consider it - but I think that developpers should be clever enough to install the hlp viewer for Windows 7.

[MVV]

I will consider it - but I think that developpers should be clever enough to install the hlp viewer for Windows 7.

Agree.


Christian,

I found an error in ContentDefaultParamStruct description (WDX API help):

typedef struct {

int size;
DWORD PluginInterfaceVersionLow;
DWORD PluginInterfaceVersionHi;
char DefaultIniName[MAX_PATH];
} ListDefaultParamStruct;

[ghisler(Author)]

I will fix it, thanks!

[MVV]

Christian, it would be great to reflect details described here in API documentation (use MaxLen parameter name for string lengths, MaxChars for buffer sizes in characters, MaxBytes for buffer sizes in Bytes, and use const modifier for input only strings/buffers/structs).

[ghisler(Author)]

Unfortunately changing these headers would probably break almost all existing plugins...

[MVV]

Christian, no one tells to authors of existing plugins to use theese headers, they can still use their own old copies. But new ones will use correct headers.

And, only a few changes in code required - to add const modifiers for pointers that work with input (constant) strings/buffers (such buffers must not be written anyway).

Also, if function prototype differs from its declaration in CPP, compiler just ignores prototype (if function is not called from another CPP by including header with prototype). Even more, it is OK when variable names in prototypes and realization differ (compiler compares only types).

[ghisler(Author)]

For example, people who add Unicode support to their plugins will get the latest headers - but this will break their existing plugins if the parameters change.

[MVV]

I doubt it will break anything. Adding Unicode requires a lot of changes anyway (all character types and strings should be converted, and Unicode strings should be called instead of old ANSI ones), so it won't be hard to add a pair of const's to code (if needed - and compiler will show all theese places, so no harm at all). As I said, no one should modify strings that I've marked as const - theese are read-only (input) strings, so there won't be any changes in logic. But it will simplify coding and improve code quality (it is a good rule to mark read-only parameters as const).

Nevertheless, as you wish.

[MVV]

Christian, please add #ifndef ... #endif preprocessor checks for header files to prevent redefinitions in case of multiple includes (which often occur in projects with multiple include files):

For WcxHead.h:

Code: Select all

#pragma once
#ifndef _WCHHEAD_H_
#define _WCHHEAD_H_


/* Contents of file wcxhead.h */
/* It contains definitions of error codes, flags and callbacks */

...
/* the rest of old wcxhead.h */


#endif // #ifndef _WCHHEAD_H_

Similar should be applied to other 3 header files (#ifndef _CONTPLUG_H_ for ContPlug.h, #ifndef _FSPLUGIN_H_ for FsPlugin.h and #ifndef _LISTPLUG_H_ for ListPlug.h). It is absolutely safe and won't break anything.

[ghisler(Author)]

Hmm, I have never had this problem - when does this occur?

[MVV]

It is a usual problem of header files, that's why such pragma exists and all standard headers contain such #ifndef.

E.g. try to compile Multiarc plugin:

multiarc.h, ArchiverManager.h:

Code: Select all

...
#include "wcxhead.h"
...

multiarc.cpp:

Code: Select all

...
#include "ArchiverManager.h"
...
#include "multiarc.h"
...

When compiler sees second definitions of same types (both multiarc.h and ArchiverManager.h include same wcxhead.h so preprocessor inserts same definitions into same source file more than once), it reports a bunch of errors.

[ghisler(Author)]

I see - just don't include header files within header files.

[MVV]

It is much easier to say than to do.
Good style tells not to define stuff that doesn't required in this source file, so there may be different header files that include some common header files (like Windows.h or WchHead.h). So it is better to have such protection in common header files.

In case of Multiarc it wasn't my fault/code so I simply added this protection to get rid of the problem.

[speller2]

Is there a way to handle the new file creation by Shift+F4 inside a FS plugin?