Are there any plugin interface changes of the upcoming TC7?

[tbeu]

With the upcoming TC7 under beta test I wonder if the plugin developers will face major plugin interface changes. If so, I am very interested to get the changes known prior the final release of TC7 to be prepared for plugin adaptions.

As I already read in this forum FS plugin will support custom columns.

Thanks from tbeu

[ghisler(Author)]

There will be a few additions to the plugin API, but all existing functions will remain backwards-compatible. Therefore no changes should be needed for existing plugins, except for adding new features. This can be done during the public beta test, which will follow the current private beta test.

[kovacsgejza]

There will be a few additions to the plugin API,

Will there be support for 64bit filesizes? Also, the 260 byte string limits seem to be a problem for me in tHeaderData. I'm trying to make a special plugin and can't finish it with these limitations, I'm hoping these will be fixed soon, thanks.

[ghisler(Author)]

Will there be support for 64bit filesizes?

Yes.

Also, the 260 byte string limits seem to be a problem for me in tHeaderData.

Unfortunately TC will keep this limit. The Explorer has it too, and it wouldn't be good if TC created files with longer names which other programs couldn't load any more. Most operating system functions are limited to 259 caracters, and longer names can only be used with some dirty tricks.

[Alextp]

There will be a few additions to the plugin API, but all existing functions will remain backwards-compatible.

Will it be possible for plugin to store (in file-record) pointer to user-defined data?

[Lefteous]

2Alextp

Will it be possible for plugin to store in file-record pointer to user-defined data?

What is a file-record pointer for user-defined data

[Alextp]

What is a file-record pointer for user-defined data

Pointer to user-defined data, which is (pointer) in file-record.
For example, dwReserved member of file-record may be this pointer,
but TC must not clear it when operating with record.

[Lefteous]

2Alextp
Can you give a concrete example where this could be useful.

[Alextp]

Can you give a concrete example where this could be useful.

Of course.

1. I needed this in MSIE Cache Browser plugin: there is no space in filerecord, where I can store URL of cache entry. So I needed to store it into FileName field, which is char[260]. All URLs longer than 260 chars are truncated so plugin cannot operate them.

2. Imagine some FS plugin which shows for example Linux file system. Where to store full Linux path of an entry, in FileName field? Again: limit of 260 chars...

[Lefteous]

2Alextp
So you just want to see a new field which is able to store longer paths?

[Alextp]

Which is able to store pointer to my data. And my data will contain longer paths. Maybe not one longer string, but several of them.

[Lefteous]

2Alextp
Do you have a concrete implementation idea? Changes to the api should't break existing plugins and new plugins should at least work (without making use of the new enhancements) when used in older TC versions.
I read a similar discussion a while ago. The idea was to introduce a unique identifier to an object in the list (different from the filename). I think these ideas are almost identical as this could be a pointer managed by the plug-in.

[Alextp]

Lefteous
I can suggest two ways:

1. Pointer can be passed through dwReserved0 and dwReserved1 fields.
TC must no clear these fields and correctly operate them.

2. Ghisler will add FsFindFirstEx/ FsFindNextEx with type Win32_Find_DataEx.
New type will contain additional fields:

- dwStructSize field as in Win API
- dwUserData discussed
- plugin-defined fields for making custom columns. This also can be pointer
- cFileNameW field (array[0..259] of WideChar) for future TC 8
- dwFlags field which determines which of additional fields are used. E.g. cFileNameW must not be used in TC 7.


First way is limited. Second way is much better IMHO...

[Lefteous]

2Alextp

Pointer can be passed through dwReserved0 and dwReserved1 fields.
TC must no clear these fields and correctly operate them.

That was also my suggestion in the other thread.

The general problem is that there are many functions which would have to be added which don't rely on a WIN32_FIND_DATA structure but just on the filename. Not impossible but a lot of work.

plugin-defined fields for making custom columns. This also can be pointer

They are implemented in a different way in TC7.

cFileNameW field (array[0..259] of WideChar) for future TC 8

Unicode questions should be answered when it's time. It's too early.

[Alextp]

That was also my suggestion in the other thread.

The general problem is that there are many functions which would have to be added which don't rely on a WIN32_FIND_DATA structure but just on the filename. Not impossible but a lot of work.

I see. So we need functions that rely on a WIN32_FIND_DATA(Ex).

Unicode questions should be answered when it's time. It's too early.

So let's wait for when it will be time.
In any way, WIN32_FIND_DATA should be extended.