Strange glitch... :(
ZXNet echo conference «zxnet.pc»
Hello, All
Interestingly, no one has encountered such a bug (checked both on the plugin for
TotalCommander, and FAR) in general, the point is that if in *.TRD or
*.SCL are ordinary files, then everything is OK, but if the AlCO archives are inside (that is, RAR), then
the plugins swear that the RAR (!) archive is crooked and don’t want to open it! what do I have to do with it
I'm trying to watch RAR - I just want to log into SCL or TRD: mad: what kind of tops?
only they scan for the presence of RAR headers and try to open it as RAR, and
not TRD or SCL... at all... :confused:
Hello, breeze
bre> if there are AlCO archives inside (that is, RAR), then the plugins are swearing like crazy
bre> RAR
This has already been written a hundred times, including and read more carefully on this forum!!!.
The fact is that plugins in FAR are loaded alphabetically, i.e. first multiarc.dll a
then xtrd.dll and xscl.dll. When you press Enter, it responds naturally first
MultiArc defines the file as its own, so it is he who swears.
To avoid this there are 2 ways.
1) Enter the image through a prefix by explicitly specifying the plugin name, for example
xscl:file.scl or xtrd:file.fdi
2) Rename multiarc.dll or all zx plugins so that they load before
multiarc
The second method has one drawback - the archives will open a little slower
because First, the file will be probed by all zx plugins at once, and only then by multiarc.
This is about FAR, but I can’t say anything about TC, I don’t use it.
Hello, Alexandr Medvedev
Ale> This has already been written a hundred times, including and read on this forum
Ale> pay attention!!!
thanks for that at least! I haven't been here for a long time...
Hello, captain cobalt
cap> MultiArc has a tool to solve the problem.
xTRD and others like it are not plugins for multiarc, so they are MultiArc API
do not use.
so what you suggest will not solve the problem...
Hello, breeze
У MultiArc имеется средство для решения проблемы.
Вот цитата из документации:
> Returns the start position of the archive in the stream of data
> passed to the IsArchive function. The function GetSFXPos is called
> immediately after the archive has been recognized by the IsArchive
> function. MultiArc selects the FMT module that has returned the
> lowest offset (closer to the beginning of the file). This allows to
> handle correctly the situation when, for example, an ARJ archive is
> stored without compression in a ZIP archive called "N3gk8v1t.106".
> Previous versions of MultiArc showed the ARJ archive, and not the ZIP
> archive, when entering such file.
>
> BOOL WINAPI GetSFXPos(void);
>
> Parameters:
> None.
>
> Return value:
> Offset of the archive beginning from the start of the file.
Hello, breeze
So the problem can be solved by redesigning it for MultiArc?
Hello, captain cobalt
cap> So the problem can be solved by redesigning it for MultiArc?
The problem can be solved by renaming MultiArc.
And by redesigning it for MultiArc, many valuable opportunities will be lost, since
MultiArc API is much smaller than FAR API.
If you can’t wait, then there is an old version of xTRD 0.4 just for MultiArc, but
I warn you, there are minimal possibilities in it.
Hello, captain cobalt
cap> So the problem can be solved by redesigning it for MultiArc?
unlikely :) especially since I don’t use MultiArc... I prefer 7-zip
like...
By the way, an alternative method of solving the problem is The Underscore.
Hello, breeze
bre> and what kind of animal is this?
http://www.warpedworld.fatal.ru/
plugin manager for FAR. one useful feature is if the file can
be processed by several plugins, a menu appears from which you can
select the correct handler. in your case you will be offered a choice:
Multiarc and xTRD (xSCL)
Hello elf/2
elf> by the way, an alternative method of solving the problem is The Underscore.
what kind of animal is this? :eek: