Plugin interface descriptions for TC 7.55 (beta)

[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?

[ghisler(Author)]

No, sorry.

[speller2]

What is a problem to add it?

[speller2]

Think it should be implemented, to avoid using pseudo-files (such as "[New file]" or "::: New file :::" in common file list.

[ghisler(Author)]

It should be doable, but I can't say yet how difficult it would be.

[speller2]

Hope it will be implemented soon

Another suggestion: add ability to FS plugins to provide custom menu items in the right-clik menu (or to replace entire menu with own items, or to provide own items and move standard items to submenu).

[KuttKatrea]

Is it possible to get a way to directly move, copy and delete folders in FS-Plugins instead of processing contents first?

I'm developing a FS-plugin for Cloud Storage Providers, but they normally use an id for each file or folders.

Associated to these id are permissions (sharing) and history, so if a folder is moved (folder-to-folder) the permissions remains untouched. But with the recreate-tree that TC uses, the folder structure is recreated and the sharing permissions for the folders are lost.

[MVV]

I support such WFX interface extension, it would be useful if plugin could perform operations with entire folders w/o recursion. Of course TC should do regular recursive operation if plugin doesn't support such feature or returns some error on such operation request in order to tell TC to perform usual operation.

I asked to add a possibility to put directories to WFX w/o recursion some years ago but with no luck.

[white]

Is it possible to get a way to directly move, copy and delete folders in FS-Plugins instead of processing contents first?

Perhaps you can present these folders as virtual files and solve it that way?