Posted: Thu Jul 07, 2005 7:19 am
Yep. And it's already possible to create activeX plugins. There's been some document on that in the past
Page 14 of 20
Posted: Sat Jul 09, 2005 6:03 pm
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.
Posted: Sat Jul 09, 2005 6:15 pm
Okido !
Posted: Thu Jul 14, 2005 9:10 pm
the find system has been completely replaced for something a little easier to use. No more crazy structures
Posted: Thu Jul 14, 2005 9:18 pm
Allright! People keep pushing me to release the new version, along with a new Scriptor/Binder, so that's good news. 
Posted: Thu Jul 14, 2005 9:19 pm
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.
Posted: Thu Jul 14, 2005 9:26 pm
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='
Posted: Thu Jul 14, 2005 9:30 pm
Almost forgot, the test plugin is litered with error information for mpGetLastError(), i'll also release a list of error values and meanings
Posted: Thu Jul 14, 2005 9:40 pm
Ok, good to know. How to address them.
Posted: Thu Jul 14, 2005 11:38 pm
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?
Extracting files
mpExportFileByNameToFile(Format, Handle, "*.WAV", "C:\AllMyWavs\")
should the plugin assume the directory exists? or should plugins force directories to exist?
Posted: Thu Jul 14, 2005 11:49 pm
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...
Posted: Thu Jul 14, 2005 11:52 pm
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.
Posted: Fri Jul 15, 2005 2:03 am
Only things left right now are
The 2 Import functions and the 2 new Remove functions for the test plugin.
The 2 Import functions and the 2 new Remove functions for the test plugin.
Posted: Fri Jul 15, 2005 6:43 am
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.
Posted: Sat Jul 23, 2005 5:33 pm
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