Listbox bug when changing file in the same drive

[browny]

Windows 8.1, TC 9.0 RC6 64-bit

Setup.
Only file names mode in both file panels.
Archive on the left (.zip will do) with a subtree packed (root and possibly subdirectories).
Right panel shows different directory in the same drive.

Enter into .zip (Ctrl+PgDn).
Search for files (Alt+F7) with empty patterns, Search archives... not checked.
Use "Feed to Listbox".
Create a file in the right panel (using editor, for example).
Rename that file with Shift+F6.

Now look at the left panel.
Tab still is Search results, but:
- it displays root directory within the archive
- panel changed mode to All file details

The same effect could be seen on exit from comparison tool after editing right file. Or after using Synchronize directories.

[silencer]

I cannot reproduce any change in the file window while creating a new file/renaming.

Going into a directory it will change from Brief to Full view indeed.

Weird thing is I can only enter top level directories, others get a open directory icon...

This is also the case in TC8.52a

Windows 10 x64 TC x64

[ghisler(Author)]

This happens when the left and right side show the same drive, and something on that drive is changed - TC then refreshes both sides. This is intentional.

[browny]

Is switching from Brief to Full view also intentional?

[ghisler(Author)]

Well, TC is already in full view for the search results.

[browny]

When you wrote "intentional", the thought was this report goes to "won't fix" subforum.
But obviously it was fixed. Thanks.
Checked both 32- and 64-bit versions of TC 9.0 final.

[ghisler(Author)]

Keeping Full was intentional, but losing the search was not really good - therefore I have fixed it. Please let me know if you find another function where this happens. For example, it happens when opening and closing the multi-rename tool. This is already on my to do list.

[browny]

I thought it was to be fixed in only one place in the code, but apparently it is not so.

First time ever the bug was spotted with .7z archive. So I went to check if plugin was responsible, but it was not, because .zip did the same.

Try the following.

The main working TC is configured to have wincmd.ini in drive C.
Prepare .7z archive in C:\tmp
Unpack TC to a new directory D:\tmp\wc (TC 9.0a rc1 32/64-bit).
Exit current TC.
Start Explorer, rename that TC's directory (no .ini or plugins now)
Start freshly unpacked TC at D:\tmp\wc.
.7z archive in the left panel, D:\tmp in the right.
Enter archive and search with empty file name.
Feed to listbox, go to any file and press F5.
Before dialog Unpack files appears, left panel should jump to the root of the archive.

[ghisler(Author)]

This isn't the same problem. In your case, it happens because TC shows the main configuration dialog. Re-reading the directories is intentional after showing the settings. Try this a second time, and it will not happen.

[browny]

This isn't the same problem.

No difference for a user: Search results were lost.

In your case, it happens because TC shows the main configuration dialog. Re-reading the directories is intentional after showing the settings. Try this a second time, and it will not happen.

32- and 64-bit versions behave very differently after start.
There are registry entries for .ini files (directory does not exist), GHISLER directory in user profile is empty.

After launch both versions show press a button dialog.
64-bit shows configuration dialog, then icons dialog, opens with one panel on both sides in full mode.
32-bit starts without initial configuration dialog, 2 tabs on each side in brief mode.

64-bit version on second attempt would unpack file.
With 32-bit there is configuraton dialog for packer every time, unpacking is impossible. Apparently it does not create directory where .ini file should have been written.

[ghisler(Author)]

With 32-bit there is configuraton dialog for packer every time

This means that you use different wincmd.ini locations for 32-bit and 64-bit, and the 32-bit version can't write to its settings. Therefore it can never store the packer options.

Please check in Help - About Total Commander where the wincmd.ini is located.

[browny]

Please check in Help - About Total Commander where the wincmd.ini is located.

Thanks for the tip; there was another wincmd.ini; and when it was deleted 32-bit version asked for initial configuration, saved .ini in roaming profile, and unpacking worked on the second attempt - good enough.

But that does not change the fact that 32-bit TC completely ignored registry setting for wincmd.ini location - unlike 64-bit version (same for tc 9.0rc2).

[ghisler(Author)]

But that does not change the fact that 32-bit TC completely ignored registry setting for wincmd.ini location

Not confirmed.

[Dalai]

2browny
I hope you're aware that 32 and 64 bit programs use different registry keys. 32 bit programs will be redirected to HKLM\Software\Wow6432Node\ instead of HKLM\Software\ key. That said, TC 32 bit will get its wincmd.ini location from \Software\Wow6432Node\Ghisler\Total Commander, at least when we're talking about the HKLM branch since HKCU is NOT redirected.

Regards
Dalai

[ghisler(Author)]

The combined 32+64-bit installer always writes the ini locations to both 32-bit and 64-bit HKLM key - if the option is checked to set it for all users, otherwise only the HKCU key is set.