PROJECT: MultiEx Plugin Support

[Mr.Mouse]

Yep. And it's already possible to create activeX plugins. There's been some document on that in the past

[Rahly]

Adding a new function, i noticed the only way to get info from archives was to use Find, which sucks if the archive doesn't support names, so i'm adding a function to get info via index number as well. I'm also toying with the idea of pulling out the Field Data from the find, this will make it easier to upgrade in the future, also taking out most of the FindDataInfo structure including filename.

[Mr.Mouse]

Okido !

[Rahly]

the find system has been completely replaced for something a little easier to use. No more crazy structures

[Mr.Mouse]

Allright! People keep pushing me to release the new version, along with a new Scriptor/Binder, so that's good news.

[Rahly]

oops, clicked submit by accident

Code: Select all

function mpFindFirstFile(ArchiveHandle: Integer; FileMask: PChar): LongWord;

for the manager though it'll be

Code: Select all

function mpFindFirstFile(FormatIndex: Integer; ArchiveHandle: Integer; FileMask: PChar): LongWord;

next

Code: Select all

function mpFindNextFile(Handle: Integer): LongBool;

Code: Select all

function mpFindNextFile(FormatIndex: Integer; Handle: LongWord): LongBool;

to get information from the find

Code: Select all

function mpFindInfo(ArchiveHandle: Integer; Handle: LongWord; Field: PChar): PChar;

Code: Select all

function mpFindInfo(FormatIndex: Integer; ArchiveHandle: Integer; Handle: LongWord; Field: PChar): PChar;

also added a function for if the archive supports ByIndex

Code: Select all

function mpIndexedInfo(ArchiveHandle: Integer; Index: Integer; Field: PChar): PChar;

Code: Select all

function mpIndexedInfo(FormatIndex: Integer; ArchiveHandle: Integer; Index: Integer; Field: PChar): PChar;

Field Information is polled by mpGetOptions using the
OPTIONTYPE_FILEINFO option.

[Rahly]

File information will be in a Format


<name>=<type>[:<size>];<name>=<type>[:<size>];

i'm defining certain static types

STRING, UINT8, UINT16, UINT32, UINT64, INT8, INT16, INT32, INT64, and DATE

so FAR

for example, FILENAME=STRING:5 = Filename is a string of characters, with a max size of 5 characters, DATE is a special case

for example 'FILEDATE=DATE;ARCHIVEDATE=DATE'

when you ask for the date you can pass format of the date, 'FILEDATE=YYYY MM DD'
or use whatever is defined in the system (if format not defined)
'FILEDATE='

[Rahly]

Almost forgot, the test plugin is litered with error information for mpGetLastError(), i'll also release a list of error values and meanings

[Mr.Mouse]

Ok, good to know. How to address them.

[Rahly]

ok, question for ya?

Extracting files

mpExportFileByNameToFile(Format, Handle, "*.WAV", "C:\AllMyWavs\")

should the plugin assume the directory exists? or should plugins force directories to exist?

[Dinoguy1000]

ok, question for ya?

Extracting files

mpExportFileByNameToFile(Format, Handle, "*.WAV", "C:\AllMyWavs")

should the plugin assume the directory exists? or should plugins force directories to exist?

Sorry for butting in like this, but I just had to say my thoughts.

Perhaps the plugin should first check for the existance of the directory, proceeding if it exhists, but asking the user if they would like to create it or specify a different directory if it doesn't...

Once again, just my thoughts...

[Rahly]

If thats the case, then it shouldn't be the plugins job, (plugin should fail/not create the directories) and it should be handled by the application.

[Rahly]

Only things left right now are

The 2 Import functions and the 2 new Remove functions for the test plugin.

[Mr.Mouse]

If thats the case, then it shouldn't be the plugins job, (plugin should fail/not create the directories) and it should be handled by the application.

I agree. That really isn't the plugin's job, it's the caller's job, in this case MultiEx Commander.

The way I see it, the user will always have to point to a directory anyway to extract in to, so that will always exist. Any subdirectories should be created, more so, when files with the same name are in different subdirs in the archive. If not allowing for subdir creation, it get's a bit messy. I think it's the end-user's job to know where he extracts what. And the plugin should just go and extract/create subdirs/overwrite files already in existing files.

[Rahly]

I'm thinking about removing the function

mpImportFileByIndexFromFile
mpImportFileByIndexFromStream

I don't see how this would work anyway.

and changing

mpImportFileByNameFromFile to

mpImportFileFromFile

and mpImportFileByNameFromStream to

mpImportFileFromStream