WDX plugin sample won't load

[baronPlug]

The wdx_filesys sample included in the documentation was hastily converted to unicode and has a few flaws as a result. Most importantly because it no longer exports the plain (not wide) ContentGetValue when built with UNICODE defined (the default as the project is setup in visual C++)

as a result the latest version of TC won't load its own sample plugin

the solution is simple, define and export both ContentGetValue and ContentGetValueW

another small but important detail is how it handles maxlen parameter in ContentGetValueW. If UNICODE is defined this should be halved, if the documentation is correct so you should have

#ifdef UNICODE
maxlen /= 2;
#endif

Also I wonder if the author is planning to add a wide version of file search data (ft_fulltextw). I saw this requested in some other threads, I just wonder if it is planned at all?

[milo1012]

it no longer exports the plain (not wide) ContentGetValue

That is correct.
The documentation clearly defines what you can do:

A:Combined Unicode/ANSI plugin

(export both functions an call it *.wdx)

B. Two separate plugins, one Unicode, one ANSI

(one .wdx, one .uwdx)

The source is therefore correct.

another small but important detail is how it handles maxlen parameter in ContentGetValueW. If UNICODE is defined this should be halved, if the documentation is correct

FieldValue is a pointer to void, and maxlen is clearly documented as "The maximum number of bytes "
So yes, you need to halve it yourself, like

Code: Select all

maxlen /= sizeof(wchar_t)

when using ContentGetValueW (no need to use some preprocessor for this, and you only need this if you return a string - for other field types it doesn't matter), and leave/use it's original value for ContentGetValue.
But this is IMO self-explanatory, since you basically get a memory buffer from TC, so as a programmer you should know what to do in case of Unicode.

The demo uses _tcslen in _tcslcpy, which automatically uses the correct functions and assumptions, depending on if Unicode is defined or not.
_tcsncat may be wrong, but it shouldn't be a problem, because it's only the maximum length, which the attribute string never reaches.

Besides, don't forget to use maxlen-1 for the term. zero in case you return a string.

[baronPlug]

The source is therefore correct.

clearly you haven;t tried to compile the sample. The resulting uwdx is not accepted by TC. It says something like "This is not a valid plugin!"...

only after adding the ansi version will it accept it. So it's either a bug in the sample or a bug with total commander, you pick what you like

[MVV]

milo1012,
In case of such mixed code it would be better to use following division:

Code: Select all

maxlen /= sizeof(TCHAR)

Personally I prefer to call variables that hold length in characters like MaxLen but ones that hold length in bytes like MaxSize or MaxBytes so my prototype for main plugin function is:

Code: Select all

int __stdcall ContentGetValueW(const wchar_t* FileName, int FieldIndex, int UnitIndex, void* FieldValue, int MaxBytes, int Flags)

baronPlug,
It is not a secret that .uwdx can't be distributed w/o corresponding .wdx:

Note: You cannot have just the .uwdx plugin if you want to create a Unicode-only plugin! Instead, create a combined Unicode/ANSI plugin, where the ANSI functions are just empty functions returning an error.

[ghisler(Author)]

Indeed you cannot just install the uwdx - install the wdx, and TC will use the uwdx if present.

Alternatively, create a combined plugin with just dummy ANSI functions - there are no more ANSI-only Windows versions supported by Microsoft. That's what I do with my new cloud plugin: Calling the ANSI only functions returns an error.

[milo1012]

clearly you haven;t tried to compile the sample

I did, and additionally I knew that uwdx alone won't work before trying, just by looking at different plugins that use Unicode.
The answers above already stated it as as clearly documented.

it would be better to use following division

What's better is a matter of personal taste.
This will only work if you follow the sample plugin's style.

TCHAR is a MS construct. This won't work as portable code.
Besides, you don't always have Windows headers with TCHAR defined.
And, like I said, you don't need to do this in general, just when returning a string (ft_stringw),
and in that case, only when limiting the string length before returning/copying it to that buffer. (until that it's just your decision if you already want to limit it)

Code: Select all

int __stdcall ContentGetValueW(const wchar_t* FileName, int FieldIndex, int UnitIndex, void* FieldValue, int MaxBytes, int Flags)

Quite gruff to simply change the function signature from wchar_t* to const wchar_t*.
A strict compiler would complain about this. Not a very "clean" style.

[MVV]

This will only work if you follow the sample plugin's style.

It is suitable for any code using TCHAR type, and it doesn't require #ifdef. I agree that it is senseless for code with direct wchar_t type.

Quite gruff to simply change the function signature from wchar_t* to const wchar_t*.

Functions are only exported by names, not by signature, so it won't hurt to add const modifier but will help me to notice read-only parameters (I'm always use such modifiers). And my header files from TC SDK contain prototypes with similar changes so compiler doesn't see anything strange.

[milo1012]

I agree that it is senseless for code with direct wchar_t type

Sure, but someone might copy this to his own style and wonder why it doesn't work.
I highly disapprove TCHAR, programs using WinAPI should be Unicode-only nowadays, Win9x is long dead.

...my header files from TC SDK contain prototypes with similar changes so compiler doesn't see anything strange

Sure, you can, but plugins use the original header contplug.h with prototypes, and the mentioned non-const function signature.
Changing it to your will is just bad style, you should honor the interface, otherwise it could make things confused or non-compiling when you update headers, or share code with other users.