Important information: this site is currently scheduled to go offline indefinitely by end of the year.
PROJECT: MultiEx Plugin Support
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.
"By nature men are alike. Through practice they have become far apart." Confucius (Analect 17:2)
oops, clicked submit by accident
for the manager though it'll be
next
to get information from the find
also added a function for if the archive supports ByIndex
Field Information is polled by mpGetOptions using the
OPTIONTYPE_FILEINFO option.
Code: Select all
function mpFindFirstFile(ArchiveHandle: Integer; FileMask: PChar): LongWord;
Code: Select all
function mpFindFirstFile(FormatIndex: Integer; ArchiveHandle: Integer; FileMask: PChar): LongWord;
Code: Select all
function mpFindNextFile(Handle: Integer): LongBool;
Code: Select all
function mpFindNextFile(FormatIndex: Integer; Handle: LongWord): LongBool;
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;
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;
OPTIONTYPE_FILEINFO option.
"By nature men are alike. Through practice they have become far apart." Confucius (Analect 17:2)
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='
<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='
"By nature men are alike. Through practice they have become far apart." Confucius (Analect 17:2)
- Dinoguy1000
- Site Admin
- Posts: 786
- Joined: Mon Sep 13, 2004 1:55 am
- Has thanked: 154 times
- Been thanked: 163 times
Sorry for butting in like this, but I just had to say my thoughts.Rahly wrote: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?
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...
-
- Site Admin
- Posts: 4073
- Joined: Wed Jan 15, 2003 6:45 pm
- Location: Dungeons of Doom
- Has thanked: 450 times
- Been thanked: 682 times
- Contact:
I agree. That really isn't the plugin's job, it's the caller's job, in this case MultiEx Commander.Rahly wrote: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.
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.
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
mpImportFileByIndexFromFile
mpImportFileByIndexFromStream
I don't see how this would work anyway.
and changing
mpImportFileByNameFromFile to
mpImportFileFromFile
and mpImportFileByNameFromStream to
mpImportFileFromStream
"By nature men are alike. Through practice they have become far apart." Confucius (Analect 17:2)