Page 3 of 6

Posted: Sat Aug 07, 2004 11:36 am
by Guest
Ok, heres my opinions. I love how you made the multiex.dll as an activex, although I don't think i would have installed it in the Windows\System directory. It allows other programs to use it like a scripting language and doesn't require its path to be known by the calling process. Now, I think the plugin files should be much simplier, like a standard DLL, your implementation is just like a dll with a wrapper around the functions into an activex. Although, activex is pretty easy for VB(it takes some of the hardness out, but is very limiting to what it can do), but its a little more difficult for other language, that have to design the activex interfaces as well as the classes. Also, you were saying that most of the functionality is in the multiex.dll, if we do it the way i described, it would be better to put the plugin functionality into the multiex.dll, this way other programs can use it, and the plugins, without having to know about them (black box theory).

Ok now onto the good stuff

Please bear with me, i wrote this up in 15 mins in Delphi (a stronger language i'm familar with)

Code: Select all

// stdcall = WINAPI style calling convention
function mpGetVersion(var Major, Minor: Integer): Boolean; stdcall;

function mpGetFormatCount(): Integer; stdcall;

type
  TFormatInfo = packed record
    // DLL Format 1.0
    FileMask: PChar;
    GameName: PChar;
    Flags: Int64;  // used for testing for what the archive can do
  end;
  // This format can be expanded on and supported based

function mpGetFormatInfo(Index: Integer; var FormatInfo: TFormatInfo): Boolean;

function mpGetCreateOptions(var CreateOptions: PChar): Boolean;

// This replaces

function mpFindFileFirst(ArchiveHandle: Integer; FilePath: PChar; var FindData: TFileFindInfo): Boolean;

function mpFindFileNext(var FindData: TFileFindInfo): Boolean;

function mpFindClose(var FindData: TFileFindInfo): Boolean;

function mpIsArchive(Index: Integer; Filename: PChar): Boolean;

function mpOpenArchive(var ArchiveHandle: Integer; FormatIndex: Integer; Filename: PChar; Flags: Cardinal; CreateOptions: PChar): Boolean;

function mpExtractFileByName(ArchiveHandle: Integer; ArchiveFile: PChar; ExternalFile: PChar): Boolean;
function mpExtractFileByIndex(ArchiveHandle: Integer; Index: Integer; ExternalFile: PChar): Boolean;

function mpImportFileByName(ArchiveHandle: Integer; ArchiveFile: PChar; ExternalFile: PChar): Boolean;
function mpImportFileByIndex(ArchiveHandle: Integer; Index: Integer; ExternalFile: PChar): Boolean;

function mpCloseArchive(ArchiveHandle: Integer): Boolean;
mpOpenArchive does opening of read only archives as well as creating new archive files if supported new archive files.

Normally the plugin will implement ByName or ByIndex but not both, ByName is for files that contain filename, ByIndex is for files that don't contain filenames but rather on position in the file, 1 for the first file 2 for the 2nd.... so on so forth..... Also when you import a file by index and pass a -1 as the index, it will append the archive with the file.

Let me know what you think of the idea, cuz there is no point in starting to write it, if we both don't agree on it.

Posted: Sat Aug 07, 2004 11:44 am
by Rahly
GRRRRRRRRRRRRRRR!

Posted: Sat Aug 07, 2004 4:31 pm
by Mr.Mouse
Ok, so what you are saying would also affect multiex.dll in a major way. Now multiex.dll is "fed" binary mex scripts to process a given archive and it will return the list (in file form). Basically the interface (the function any program would call multiex.dll with) should only need a bit of changing. Multiex.dll should then check a standard directory for any plugins.

I can dig your approach. You would need the latest multiex.dll source files to do that. The existing plugins (Painkiller.dll and sacrifice.dll) can be rewritten to adapt to your interface.

I will update the CVS (as it failed yesterday) and then you will have the latest files on multiex.dll and the scriptor (which should work with the latest multiex.dll always!).

If you wish you can then adapt the code to your plan of the new plugin approach. If you do, I will officially add you as coworker on Sourceforge. ;)

[EDIT] I have updated the CVS. It should have the latest source files for multiex.dll and the scriptor.

Posted: Sat Aug 07, 2004 4:58 pm
by Rahly
Question

multiex.dll is just a compiler right now?... input source, output binary? or does it do the executing of binary also?

If its just a compiler, there is no sense in modifying it. Another approach would to make a new DLL, One that is "similar" to an active x control, BUT exports the same functions as a plugin. This "plugin" will actually be a semi filter, to you it would look like a plugin, but in fact, it would process the MEX scripts(MRF File) and the other plugins.

EI.

mpOpenArchive(5) is actually a MEX script, and uses the MEX script to open and process the archive.

mpOpenArchive(6) is actually a plugin, and instead of processing, it just "reroutes" the call to the plugin, and returns the plugin values.

Also, GetFormatCount() should return a count of all formats, (MEX or otherwise)

To do it this way, will remove most of the processing out of the main application, thereby turning the main application into a gui "interface" to the archiving module.

MainGUI -> mexrun.dll -> MEXScript
MainGUI -> mexrun.dll -> Plugin

Also, I'd like to change ExtractFile so that instead of taking JUST a file name, it will take wildcards.

ExtractFile(ArchiveHandle, '*.tga', 'C:\MyTGAs\') should extract all TGAs to the directory C:\MyTGAs

ExtractFile(ArchiveHandle, '*.bin', 'C:\MyTGAs\*.tga') should extract all bin files from the archive and save them as TGAs on the C drive.

ImportFile should work roughly the same way.

I'll just need the binary encoding of the MEX script.

Note: This will also allow us to build a "test" suite for the DLLs or Plugins, that help keep bugs down.

Posted: Sat Aug 07, 2004 5:00 pm
by Rahly
Just to let you know, the mp i tack onto the begining of function names stands for MultiEx Plugin. :-D

Posted: Sat Aug 07, 2004 5:09 pm
by Mr.Mouse
Multiex.dll takes a script that was "compiled" by MexScriptor to an array of function codes and variables. It "runs" through this array and performs the functions that the codes resemble. If the script uses the command "Log" this will be result in an entry in a list file, with multiex.dll saving the filename, the offset of this filename, the size of this filename, the offset of the offsetpointer, the offset of teh sizepointer). At the end the script should stop at which point multiex.dll is done.

There's a little info in the source files about how this works, and what the format of a .BMS file is (multiex script compiled to an array of functions and variables).

The nice feature of the plugin system at this point is that the plugin can tell MultiEx Commander what variables it will return, so that MultiEx COmmander can assign the appropriate number of columns in the interface to the user. This should be kept I think. Also, the plugin can tell MultiEx Commander what questions to ask the user (i.e. what settings the user should specify) prior creation of a new archive (e.g. compression or no compression, filenames or indexes, or whatever the format should be able to handle).

Posted: Sat Aug 07, 2004 5:38 pm
by Rahly
Mr.Mouse wrote:Multiex.dll takes a script that was "compiled" by MexScriptor to an array of function codes and variables. It "runs" through this array and performs the functions that the codes resemble. If the script uses the command "Log" this will be result in an entry in a list file, with multiex.dll saving the filename, the offset of this filename, the size of this filename, the offset of the offsetpointer, the offset of teh sizepointer). At the end the script should stop at which point multiex.dll is done.
Ok its the VM... I just though of an idea, this fliter plugin could call the multiex.dll when it needs to do script access. This will leave the MEX scripts still completely in your hands, the only thing, The Gui won't call the multiex.dll directly, but instead call the filter plugin.
Mr.Mouse wrote:There's a little info in the source files about how this works, and what the format of a .BMS file is (multiex script compiled to an array of functions and variables).
Gotcha, but if we do what i suggested, then I wouldn't need to know the formats of the MEX script files.
Mr.Mouse wrote:The nice feature of the plugin system at this point is that the plugin can tell MultiEx Commander what variables it will return, so that MultiEx COmmander can assign the appropriate number of columns in the interface to the user. This should be kept I think. Also, the plugin can tell MultiEx Commander what questions to ask the user (i.e. what settings the user should specify) prior creation of a new archive (e.g. compression or no compression, filenames or indexes, or whatever the format should be able to handle).
The format of the plugins still has this.

function mpGetCreateOptions(var CreateOptions: PChar): Boolean;

which instead of returning it as an array, its returns it all in one string. Now, the filter plugin would be able to parse this back into an array for you IF you want.

Format of the string will be

'<VARIABLE>:<TYPE>=<DESCRIPTION>;<VARIABLE>:<TYPE>=<DESCRIPTION>'

then in the OpenArchive for the CreateParams you do something similar

'<VARIABLE>=<VALUE>'

<VARIABLE> is the Variable name for create archive
<TYPE> is the variable type(ie Integer/Filename/String/etc)
<DESCRIPTION> is what the user interface should tell the user in a popup or a help message
<VALUE> is what to set the variable to

Well, for the first, i did see that, but i wanted a while to "think" about it. How about this

Actually I was just going to suggest a field in the FormatInfo data, but I have a better Idea

function mpGetFormatFields(FormatIndex: Integer; LanguageId: Integer; var Data: PWChar): Boolean;

This will allow 2 things. Allow the plugin to hold information per format, but also allow the plugin to hold multiple languages, and the current language ID can be grabbed from the Locale and passed in.

Format of the string would be

'<FIELD NAME>=<DISPLAY NAME>;'

Then I can modify FindFirstFile to accept a string of Field names
'<FIELD NAME>;<FIELD NAME>'

Posted: Sat Aug 07, 2004 5:52 pm
by Mr.Mouse
Some very good ideas indeed. I like that.

Yes, we should have a filter that handles the "legacy" multiex.dll (passes stuff to it), it will be easy to adapt the GUI to call the filter/wrapper. You need not concern yourself with multiex.dll then. ;)

I also say we can worry about the GUI later.

Priority should be having a working new method of plugins and legacy script. I can then (re)write parts of MultiEx Commander to start to work with the new system. You can tell me what the GUI should do and not do with your plugin interface, and I will work it out.

Thus, that makes you in full charge of the Plugin Interface & Plugin Implementation, if you want that, along with any other cool ideas ou may have of coure. :) I shall give you your place in the project at Sourceforge. Have you already registered there?

Posted: Sat Aug 07, 2004 6:19 pm
by Rahly
Mr.Mouse wrote:Some very good ideas indeed. I like that.

Yes, we should have a filter that handles the "legacy" multiex.dll (passes stuff to it), it will be easy to adapt the GUI to call the filter/wrapper. You need not concern yourself with multiex.dll then. ;)
or i could write the filter plugin too, not a big issue
Mr.Mouse wrote:I also say we can worry about the GUI later.

Priority should be having a working new method of plugins and legacy script. I can then (re)write parts of MultiEx Commander to start to work with the new system. You can tell me what the GUI should do and not do with your plugin interface, and I will work it out.
sounds good to me
Mr.Mouse wrote:Thus, that makes you in full charge of the Plugin Interface & Plugin Implementation, if you want that, along with any other cool ideas ou may have of coure. :) I shall give you your place in the project at Sourceforge. Have you already registered there?
I have a login, but its been so long since i used it. I wonder if its still there. Let me get the plugin system actually built with a test suite. And I'll resign up or get my old password

Posted: Sat Aug 07, 2004 6:27 pm
by Rahly
Ok Here is my Semi sample for a delphi plugin with YOUR plugin interface

project1.dpr

Code: Select all

library Project1;

uses
  ComServ,
  Project1_TLB in 'Project1_TLB.pas',
  Unit1 in 'Unit1.pas' {Archive: CoClass};

exports
  DllGetClassObject,
  DllCanUnloadNow,
  DllRegisterServer,
  DllUnregisterServer;

{$R *.TLB}

{$R *.RES}

begin
end.
Unit1.pas

Code: Select all

unit Unit1;

{$WARN SYMBOL_PLATFORM OFF}

interface

uses
  Windows, ActiveX, Classes, ComObj, Project1_TLB, StdVcl, SysUtils, Direct3D9;

type
  Tarchive = class(TAutoObject, Iarchive)
  protected
    function bnPlugInfo(var Info: OleVariant): OleVariant; stdcall;
    function bnIdentify(Filename: OleVariant): WordBool; stdcall;
    {Declare Iarchive methods here}
  end;

implementation

uses ComServ, Variants;

function Tarchive.bnPlugInfo(var Info: OleVariant): OleVariant;
var
  Info2: OleVariant;
begin
  Info2 := VarArrayCreate([0, 10], varOleStr);
  Info2[0] := 'This is my New Game';
  Info2[1] := '2';
  Info2[2] := '1.0';
  Info2[3] := '0';
  Info2[4] := '1';
  Info2[5] := '0';
  Info2[6] := '0';
  Info2[7] := '0';
  Info2[8] := '0';
  Info2[9] := '0';
  Info2[10] := 'Filename';
  Info := Info2;
end;

function Tarchive.bnIdentify(Filename: OleVariant): WordBool;
begin
  Result := False;
end;

initialization
  TAutoObjectFactory.Create(ComServer, Tarchive, Class_archive,
    ciMultiInstance, tmApartment);
end.
Project1_TLB.pas

Code: Select all

unit Project1_TLB;

// ************************************************************************ //
// WARNING                                                                    
// -------                                                                    
// The types declared in this file were generated from data read from a       
// Type Library. If this type library is explicitly or indirectly (via        
// another type library referring to this type library) re-imported, or the   
// 'Refresh' command of the Type Library Editor activated while editing the   
// Type Library, the contents of this file will be regenerated and all        
// manual modifications will be lost.                                         
// ************************************************************************ //

// PASTLWTR : 1.2
// File generated on 8/7/2004 11:19:04 AM from Type Library described below.

// ************************************************************************  //
// Type Lib: C:\Program Files\Borland\Delphi7\Projects\Auto\Project1.tlb (1)
// LIBID: {218D0DCD-767C-487E-8B97-CD9785F39F63}
// LCID: 0
// Helpfile: 
// HelpString: Project1 Library
// DepndLst: 
//   (1) v2.0 stdole, (C:\WINDOWS\System32\STDOLE2.TLB)
// ************************************************************************ //
{$TYPEDADDRESS OFF} // Unit must be compiled without type-checked pointers. 
{$WARN SYMBOL_PLATFORM OFF}
{$WRITEABLECONST ON}
{$VARPROPSETTER ON}
interface

uses Windows, ActiveX, Classes, Graphics, StdVCL, Variants;
  

// *********************************************************************//
// GUIDS declared in the TypeLibrary. Following prefixes are used:        
//   Type Libraries     : LIBID_xxxx                                      
//   CoClasses          : CLASS_xxxx                                      
//   DISPInterfaces     : DIID_xxxx                                       
//   Non-DISP interfaces: IID_xxxx                                        
// *********************************************************************//
const
  // TypeLibrary Major and minor versions
  Project1MajorVersion = 1;
  Project1MinorVersion = 0;

  LIBID_Project1: TGUID = '{218D0DCD-767C-487E-8B97-CD9785F39F63}';

  IID_IArchive: TGUID = '{174CFDA1-86D5-467B-BCE1-88D525FF0795}';
  CLASS_Archive: TGUID = '{4A61A49C-6659-49A3-8C4D-4E3F1BF72430}';
type

// *********************************************************************//
// Forward declaration of types defined in TypeLibrary                    
// *********************************************************************//
  IArchive = interface;

// *********************************************************************//
// Declaration of CoClasses defined in Type Library                       
// (NOTE: Here we map each CoClass to its Default Interface)              
// *********************************************************************//
  Archive = IArchive;


// *********************************************************************//
// Declaration of structures, unions and aliases.                         
// *********************************************************************//
  POleVariant1 = ^OleVariant; {*}
  PHResult1 = ^HResult; {*}


// *********************************************************************//
// Interface: IArchive
// Flags:     (4352) OleAutomation Dispatchable
// GUID:      {174CFDA1-86D5-467B-BCE1-88D525FF0795}
// *********************************************************************//
  IArchive = interface(IDispatch)
    ['{174CFDA1-86D5-467B-BCE1-88D525FF0795}']
    function bnPlugInfo(var Info: OleVariant): OleVariant; stdcall;
    function bnIdentify(Filename: OleVariant): WordBool; stdcall;
  end;

// *********************************************************************//
// The Class CoArchive provides a Create and CreateRemote method to          
// create instances of the default interface IArchive exposed by              
// the CoClass Archive. The functions are intended to be used by             
// clients wishing to automate the CoClass objects exposed by the         
// server of this typelibrary.                                            
// *********************************************************************//
  CoArchive = class
    class function Create: IArchive;
    class function CreateRemote(const MachineName: string): IArchive;
  end;

implementation

uses ComObj;

class function CoArchive.Create: IArchive;
begin
  Result := CreateComObject(CLASS_Archive) as IArchive;
end;

class function CoArchive.CreateRemote(const MachineName: string): IArchive;
begin
  Result := CreateRemoteComObject(MachineName, CLASS_Archive) as IArchive;
end;

end.
Although, this isn't a very USABLE plugin, it will be seen by MultiEx Commander and executed properly.

Posted: Sat Aug 07, 2004 6:36 pm
by Rahly
Bug fix for the current plugin system

Code: Select all

Public Function Mex_FindPlugIns() As Long
Dim LD, t, t2, SubFolder, File
Dim f As Folder
Dim D, E
Dim handle
'f.path
DebugLog "-Main : Mex_FindPlugins"


Set D = New FileSystemObject
Set E = New FileSystemObject
On Error Resume Next
Set f = D.GetFolder(MainPath)
Set f = D.GetFolder(MainPath & "\" & MultiExPlugInPath)
On Error GoTo 0

If f.path <> MainPath Then

DebugLog "-Main : Mex_FindPlugins->Searching"

LD = 1
While LD <= f.SubFolders.Count

t = 0
For Each SubFolder In f.SubFolders
Dim ts, nu
ts = SubFolder.Name

'RAHLY 3 Lines
If Len(ts) < 3 then
  ts = Pad(ts,3)
End If

t = 0
While formats(t).Extension <> UCase(ts) And t <= ExtFormats
t = t + 1
Wend
If t <= ExtFormats + 1 Then
nu = formats(t).Number

nu = nu + SubFolder.Files.Count

ReDim Preserve formats(t).Games(nu)

formats(t).Number = nu
t2 = 1
For Each File In SubFolder.Files
formats(t).Games(nu - t2).Execute = "PGN"
formats(t).Games(nu - t2).FPath = File.path
formats(t).Games(nu - t2).GameName = E.GetBaseName(File.Name)
'handle = LoadLibrary(formats(t).Games(nu - t2).FPath)
DebugLog "-Main : Mex_FindPlugins->" & _
formats(t).Games(nu - t2).Execute & " at " & _
RTrim(formats(t).Games(nu - t2).FPath) & " for " & _
RTrim(formats(t).Games(nu - t2).GameName)
TotalForm = TotalForm + 1

' Rahly 3 Lines  Note: This will only work if VB6 doesn't need to
'   ReDim the "formats" variable
If T > ExtFormats then
  ExtFormats = ExtFormats + 1
End If

'ReDim Preserve Extfilter



'Dim FP

'FP = GetProcAddress(handle, "DllGetClassObject")
t2 = t2 + 1
Next
End If



t = t + 1
Next

LD = LD + 1
Wend
ReDim Preserve FExt(TotalForm)
ReDim Preserve FilterExt(TotalForm)
Else
DebugLog "-Main : Mex_FindPlugins->None found"
End If
'End If



End Function
Look for Rahly in the code, for code changes, and make sure they are in the newest version

Posted: Sat Aug 07, 2004 7:44 pm
by Rahly
Also, I'd like to request a change, it may have some problems with your currently implemented system, but hear me out.

Instead of the plugin registering an extension, I was thinking of registering as a "file mask"

Instead of saying "EXT" you would say "*.arch" or "*.PK?" meaning any file with an extentions of arch or... any extension with a PK<something>.

This would almost infinitely expand setting a file extension to a game. or if you think thats a little too much

"arch" and "PK?" without the beginning *., but still allow wildcards in the extension.

Posted: Sat Aug 07, 2004 8:02 pm
by Mr.Mouse
Yes, we need that.

One thing though, you are working NOT with the latest code, apparently, because you made changes in my old plugin detection code.

Here is the current code for it, I think it does not have that problem you described earlier.
Public Function Mex_FindPlugIns() As Long
Dim LD, t, t2, SubFolder, File
'Dim f As Folder
Dim handle
Dim cFiles As New colFiles

DebugLog "-Main : Mex_FindPlugins"



On Error Resume Next

cFiles.Clear
cFiles.LoadFiles MainPath & "\" & MultiExPlugInPath & "*.dll", True
On Error GoTo 0

If cFiles.Count > 0 Then

DebugLog "-Main : Mex_FindPlugins->Searching"

'LD = 1
'While LD <= f.SubFolders.Count
Dim t3, D
t = 0

For t3 = 1 To cFiles.Count
Dim ts, nu
D = Len(MainPath & "\" & MultiExPlugInPath)
ts = Right(cFiles.Item(t3).sFilename, Len(cFiles.Item(t3).sFilename) - (D))
ts = MexGetParentFolderName(ts)

t = 0
While formats(t).Extension <> UCase(ts) And t <= ExtFormats
t = t + 1
Wend
If t <= ExtFormats + 1 Then
nu = formats(t).Number

nu = nu + 1

ReDim Preserve formats(t).Games(nu - 1)

formats(t).Number = nu
t2 = 1

'If MexGetExtensionName(cFiles.Item(t3).sFilename) = "dll" Then


formats(t).Games(nu - t2).Execute = "PGN"
formats(t).Games(nu - t2).FPath = cFiles.Item(t3).sFilename
formats(t).Games(nu - t2).GameName = MexGetBaseName(cFiles.Item(t3).sFilename)
'handle = LoadLibrary(formats(t).Games(nu - t2).FPath)
DebugLog "-Main : Mex_FindPlugins->" & _
formats(t).Games(nu - t2).Execute & " at " & _
RTrim(formats(t).Games(nu - t2).FPath) & " for " & _
RTrim(formats(t).Games(nu - t2).GameName)
TotalForm = TotalForm + 1

'End If

End If



t = t + 1
Next t3

'LD = LD + 1
'Wend
ReDim Preserve FExt(TotalForm)
ReDim Preserve FilterExt(TotalForm)
Else
DebugLog "-Main : Mex_FindPlugins->None found"
End If
'End If



End Function

Posted: Sat Aug 07, 2004 8:14 pm
by Rahly
Mr.Mouse wrote:Yes, we need that.

One thing though, you are working NOT with the latest code, apparently, because you made changes in my old plugin detection code.

Here is the current code for it, I think it does not have that problem you described earlier.

Code: Select all

Public Function Mex_FindPlugIns() As Long
Dim LD, t, t2, SubFolder, File
'Dim f As Folder
Dim handle
Dim cFiles As New colFiles

DebugLog "-Main : Mex_FindPlugins"



On Error Resume Next

cFiles.Clear
cFiles.LoadFiles MainPath & "" & MultiExPlugInPath & "*.dll", True
On Error GoTo 0

If cFiles.Count > 0 Then

DebugLog "-Main : Mex_FindPlugins->Searching"

'LD = 1
'While LD <= f.SubFolders.Count
Dim t3, D
t = 0

For t3 = 1 To cFiles.Count
Dim ts, nu

'This might be fixed
D = Len(MainPath & "" & MultiExPlugInPath)
ts = Right(cFiles.Item(t3).sFilename, Len(cFiles.Item(t3).sFilename) - (D))
ts = MexGetParentFolderName(ts)

t = 0
While formats(t).Extension <> UCase(ts) And t <= ExtFormats
t = t + 1
Wend
'Still not fixed here
If t <= ExtFormats + 1 Then
nu = formats(t).Number

nu = nu + 1

ReDim Preserve formats(t).Games(nu - 1)

formats(t).Number = nu
t2 = 1

'If MexGetExtensionName(cFiles.Item(t3).sFilename) = "dll" Then


formats(t).Games(nu - t2).Execute = "PGN"
formats(t).Games(nu - t2).FPath = cFiles.Item(t3).sFilename
formats(t).Games(nu - t2).GameName = MexGetBaseName(cFiles.Item(t3).sFilename)
'handle = LoadLibrary(formats(t).Games(nu - t2).FPath)
DebugLog "-Main : Mex_FindPlugins->" & _
formats(t).Games(nu - t2).Execute & " at " & _
RTrim(formats(t).Games(nu - t2).FPath) & " for " & _
RTrim(formats(t).Games(nu - t2).GameName)
TotalForm = TotalForm + 1

' Rahly 3 Lines  Note: This will only work if VB6 doesn't need to 
'   ReDim the "formats" variable 
If T > ExtFormats then 
  ExtFormats = ExtFormats + 1 
End If 


'End If

End If



t = t + 1
Next t3

'LD = LD + 1
'Wend
ReDim Preserve FExt(TotalForm)
ReDim Preserve FilterExt(TotalForm)
Else
DebugLog "-Main : Mex_FindPlugins->None found"
End If
'End If



End Function
There were 2 problems, and they are both present in the version of MultiEx that i have, 4.0.1 ? Look at "TotalForm = TotalForm + 1"

And About the FileMask, I didn't know what was involved in the MEX scripts. So I wanted to ask.

Posted: Sat Aug 07, 2004 8:23 pm
by Mr.Mouse
Good, I used that last code bit and it ran.
I will take a look at it in the future.

As for the filemasks, yes, I think we should do that. I will see that I fix the system in the Commander so that it will regiter as that. I think I will need a new way of handling the different formats supported, perhaps. Or at least just for the plugins anyway. I think it won't be too much trouble.

I don't readily see the benefit of "*.arch?" over "arch?", so I think the "arch?" approach will do nicely for the plugins. Perhaps I need to fix that stuff also for the script-processed formats, but that will require a bit more work, as the ScriptBinder (MexBinder) needs to be fixed for that as well.