Ctrl-PgDwn not opening exe archives any more

[Fla$her]

The Filter8_open=** setting does NOT result in an item in the context menu - so my first item in the context menu is "Internal 7zip"

You're wrong. The first element in this case will be called "Open". When I select it, the archive opens in Explorer (TC4Shell).

Dialog box: Edit file type (internal associations)
...
** A double asterisk opens the file with the default system association

I tried your setting, and when pressing Enter /double-click on a .7z file it will open it with the Internal unpacker, and then I cannot ADD files to the archive

The point is to use the fastest way possible to open for viewing and unpacking. Therefore, Total7zip is used for more rare cases when it is necessary to add files to the archive, where the hotkey with cm_ContextMenuInternalCursor helps.

I tried your setting - it seems that you didn't bother to try mine...?

I would not check your scheme exactly, because 7z_7z is not the default setting. The rest has been checked long ago.

If I set up a hotkey for the cm_ContextMenuInternalCursor, I'll have to remember that hotkey for the rare occasions, where I don't want the file opened with Total/zip.

I wish I knew about these "rare" occasions. You don't need to remember the hotkey just for the sake of one extension, internal associations aren't limited to it. For me, this isn't a problem at all, because the hotkey is so banal that I didn't even have to remember it: Ctrl + Menu/AppsKey.

[petermad]

You're wrong. The first element in this case will be called "Open". When I select it, the archive opens in Explorer (TC4Shell).

Well not here: https://tcmd.madsenworld.dk/7zcontextmenu.png

** A double asterisk opens the file with the default system association

I know that the help file says that, but for archive types registered in TC, TC uses the registered archive type as the default association - unless [Packer] ZIPlikeDirectory=0 is set.

I would not check your scheme exactly, because 7z_7z is not the default setting. The rest has been checked long ago.

7z_7z if for the 7zip plugin - if you don't have that plugin installed, then leave it out - please just try this .ini file:

Code: Select all

[Configuration]
UseNewDefFont=1
SetEncoding=äö.do.not.remove
firstmnu=2618
FirstTimeIconLib=0
FirstTime=0
FirstTimeUnpack=0

[Associations]
Filter1=*.7z
Filter1_open=**
Filter1_Internal 7zip=**internal_7z
Filter1_Total7zip plugin=**7z

[PackerPlugins]
7z=735,%COMMANDER_PATH%\PLUGINS\wcx\Total7zip\Total7zip.wcx

And tell me if you see an Open item at the top of the context menu.

This suits me because I want to open with Total7zip plugin as default.


For opening with internal unpacker by default it could be:

Code: Select all

[Configuration]
UseNewDefFont=1
SetEncoding=äö.do.not.remove
firstmnu=2682
FirstTimeIconLib=0
FirstTime=0
FirstTimeUnpack=0
SeparateTree=0
PanelsVertical=0

[Associations]
Filter1=*.7z
Filter1_open=**
Filter1_Internal 7zip=**internal_7z
Filter1_Total7zip plugin=**7zip_7z

[PackerPlugins]
7zip_7z=735,%COMMANDER_PATH%\PLUGINS\wcx\Total7zip\Total7zip.wcx

or your solution.

The point is to use the fastest way possible to open for viewing and unpacking

Is there any evidence that the internal unpacker is faster than the Total7zip plugin? This is not a retorical question - I ask because I don't know.

[Fla$her]

And tell me if you see an Open item at the top of the context menu.

For cm_ContextMenuInternalCursor, which I use, there is. I don't use the usual context menu for archives at all due to the slow first appearance and redundancy.

Is there any evidence that the internal unpacker is faster than the Total7zip plugin?

I don't have a debugger to test this on, so it's just intuitive for large archives. I don't think Christian would have added this functionality without some benefit. In addition, something was debugged for new versions of 7z.dll and not only. For example:

27.08.23 Fixed: The internal 7zip unpacker could no longer open and unpack multi-part 7zip archives, because the updated 7zip DLL requests the size of all parts (32/64)
04.07.23 Fixed: Updated 7zip unpacker dlls (TC7Z.DLL/TC7Z64.DLL) to version 23.01, fixed crash in 64-bit caused by the new dll (32/64)
11.02.20 Fixed: Search in 7z archives with internal 7zip unpacker was much slower than extracting the same archive (32/64)
08.05.15 Added: Synchronize dirs, speed up unpacking from solid 7zip archives - it was very slow because each file was unpacked separately (32/64)
10.12.13 Added: Search function, search for file contents: Do not unpack files <1MB from 7zip to TEMP, but instead to memory -> much faster (32/64)

[petermad]

And tell me if you see an Open item at the top of the context menu.

For cm_ContextMenuInternalCursor, which I use, there is. I don't use the usual context menu for archives at all due to the slow first appearance and redundancy.

That is not what I asked for - humor me and try the first .ini file I posted here above.


I tested searching for content in files inside archives - if 7z is associated with a plugin in the [PackerPlugins] section, then TC uses the plugin - not the internal unpacker (to test rename the 7z.dll file in your 7zip program folder).

My guess is that Ghisler added the internal 7z unpacker, so people without plugins can still open and unpack 7z archives - not to speed up things.
Unlike RAR, LHA, ARJ. and ACE unpacking, TC does not offers an option: "Use internal un-7Z if possible"

[Fla$her]

That is not what I asked for - humor me and try the first .ini file I posted here above.

It's a strange reaction. How could I tell you about the result for the context menu without testing your code? o_0
You didn't specify which of the mentioned context menus you are interested in. There was a hint of a difference in the results in the response.
By the way, I found one unpleasant thing with your settings: when writing Filter№=*.7z;*.7zip, an empty AnyName.7zip opens with an external program by pressiing Enter.

I tested searching for content in files inside archives

And what are the results?

My guess is that Ghisler added the internal 7z unpacker, so people without plugins can still open and unpack 7z archives - not to speed up things.

And I think this is due to some complaints about interaction with plugins (memory problems, etc.), so it became necessary to add support for a popular archive type in order to independently debug interaction with libraries. An internal implementation with debugged memory allocation and other things gives its advantages in read and initialization speed, as was done, for example, when implementing libdeflate for ZIP and GZIP.

22.12.22 Added: High speed packing and unpacking with modified libdeflate now also of GZIP files (but not tar.gz) (32/64)
16.12.22 Added: High speed packing and unpacking of ZIP files with modified libdeflate library (32/64)[/qoute]

[petermad]

You didn't specify which of the mentioned context menus you are interested in.

Well, I did - I asked for testing the context menu not the the context menu for internal associations.
Anyway - all I would like to have confirmed is that my setting does NOT generate an Open item in the top of the normal Windows context menu (Right-click, Shift+F10 or the Windows keyboard context menu button). We've already established that my setting does generate an Open item in the internal context menu - I don't dispute that.

By the way, I found one unpleasant thing with your settings: when writing Filter№=*.7z;*.7zip, an empty AnyName.7zip opens with an external program by pressiing Enter.

Hmm. not here - is that when you press enter on a .7z file or a .7zip file - or both?
It could be because we might have different settings in the [PackerPlugins] section - what are your accoiations for 7z and 7zip in that section?
Do you have a global Windows association for .7zip (I don't, because the 7zip program does not offer to associate .7zip files.

And what are the results?

I did not test the speed - I tested whether the internal unpacker OR Total7zip is used when searching the content of .7z files. I did that by renaming 7zip's 7z.dll file, which gives me an error message when searching for conten - which shows me that TC uses 7zip (via the plugin) and not the internal unpacker. So if Total7zip is installed in TC, the question of which method is the fastest is academic, since the unpacking with the plugin is always used. As I wrote: there is NO "Use internal un-7Z if possible" option in TC

In other words - If you have Total7zip configured as a packer plugin for .7z files - then you must not think that you get any speed benefits from the internal 7z unpacker when searching content, because the internal unpacker is not used under that circumstance.

[Fla$her]

Well, I did

No. I repeat: there is no clarification in the quote I have given.

all I would like to have confirmed is that my setting does NOT generate an Open item in the top of the normal Windows context menu

I've already done that:

There was a hint of a difference in the results in the response.

, which means the presence of this item in the internal associations menu and its absence in the system one. Everything seems to be obvious.

Hmm. not here - is that when you press enter on a .7z file or a .7zip file - or both?

Everything is exactly as I wrote it. No more, no less. I didn't complain about .7z.

It could be because we might have different settings in the [PackerPlugins] section - what are your accoiations for 7z and 7zip in that section?

Unlike 7z=, I don't have a line with 7zip= either, so no difference in behavior is expected for empty and non-empty archives, but nevertheless it's there.

Do you have a global Windows association for .7zip

I wrote about it above — TC4Shell.

I did not test the speed - ...

It's clear now.

then you must not think that you get any speed benefits from the internal 7z unpacker when searching content

I'm not that interested in speeding up archive searches, I rarely do that.