Name column can sort incorrectly after feed to listbox

The behaviour described in the bug report is either by design, or would be far too complex/time-consuming to be changed

Moderators: white, Hacker, petermad, Stefan2

Post Reply
User avatar
jdmarch
Member
Member
Posts: 161
Joined: 2003-03-12, 02:34 UTC
Location: Austin, Texas, USA

Name column can sort incorrectly after feed to listbox

Post by *jdmarch »

Task: after feeding search results to a listbox, sort by filename.
Problem: the built-in "Name" column includes path in this context.

First attempt: include a custom column [=tc.path]. Now the"Name" column automagically displays only filenames, not paths. Great!
Problem: But the "Name" column still sorts by the path which it is not displaying, rather than by the filename that it is displaying.
Bug?: This seems like a bug to me; you expect a column to sort on its visible contents.

Next attempt: Use custom columns [=tc.name] and/or [=tc.ext]., and try to disappear the built-in Name and Ext column.
Problems: The built-in columns Name and Ext cannot be moved or made to disappear. Also the useful filetype/folder icons are in Name but not in [=tc.name].

Final attempt: Apparently the best I can do is to make Name column 10 units wide and make Ext column 20 units wide, which causes some pixel pollution between these columns, but not too bad. After these comes [=tc.name], which is a counter-intuitive display order (extension before name).

Proposal: Make the Name column sort on its displayed contents.

This has been reported before in much less detail, but I did not see any discussion of it. See the last post of: http://ghisler.ch/board/viewtopic.php?t=7268
User avatar
ghisler(Author)
Site Admin
Site Admin
Posts: 48097
Joined: 2003-02-04, 09:46 UTC
Location: Switzerland
Contact:

Post by *ghisler(Author) »

This is indeed intentional to get consistent sort orders for full view and custom columns view. I have considered to sort by displayed names also for other fields or field parts, but it would lead to a big number of problems (e.g. when sorting by parts of numeric fields)...
Author of Total Commander
https://www.ghisler.com
User avatar
jdmarch
Member
Member
Posts: 161
Joined: 2003-03-12, 02:34 UTC
Location: Austin, Texas, USA

Post by *jdmarch »

Thanks. I think I understand you, but of course by holding to one kind of consistency you've introduced an inconsistency with standard user expectations, which is that a plain filename column will sort on plain filename. Maybe an option...?
User avatar
karlchen
Power Member
Power Member
Posts: 4603
Joined: 2003-02-06, 22:23 UTC
Location: Germany

Re: Name column can sort incorrectly after feed to listbox

Post by *karlchen »

Hello, jdmarch.
Final attempt: Apparently the best I can do is to make Name column 10 units wide and make Ext column 20 units wide, which causes some pixel pollution between these columns, but not too bad. After these comes [=tc.name], which is a counter-intuitive display order (extension before name).
All right, here is the workaround which looks and works in a satisfying way here (just a modification of your idea :wink: ):

Code: Select all

[CustomFields]
AutoLoad=0
Titles=Search Results
Widths1=10,5,200,350,-60,-60,-20
Headers1=Name\nFolder\nSize\nDate\nAttr
Contents1=[=tc.fullname]\n[=tc.path]\n[=tc.size]\n[=tc.writedate]\n[=tc.attributestr]
Options1=-1|1
You may have to adjust the chosen column widths a bit to match your display.
The unremovable EXT column is reduced to 5. You can still click on it to sort by extension. But the extension will not be visible any longer here.
The next column NAME [=tc.fullname] holds name plus extension. Thus you see name and extension in the right order.
You can sort by this column NAME (=tc.fullname).

Kind regards,
Karl
User avatar
jdmarch
Member
Member
Posts: 161
Joined: 2003-03-12, 02:34 UTC
Location: Austin, Texas, USA

Post by *jdmarch »

Karl, thank you for the thought and the work. Unfortunately this does not make an improvement from my perspective. Unless the unremoveable EXT column is widented to 20, it pollutes the following name column. And once I've widened it, there's no reason (at least from my perspective) to use tc.fullname instead of tc.name -- it just wastes screen space.

For the record, this seems to be my best workaround:

Code: Select all

Widths3=10,20,90,63,-30,400,80
Headers3=name\nDate\nSize\nPath\nAttr
Contents3=[=tc.name]\n[=tc.writedate]\n[=tc.size.bkMG2]\n[=tc.path]\n[=tc.attributestr]
User avatar
karlchen
Power Member
Power Member
Posts: 4603
Joined: 2003-02-06, 22:23 UTC
Location: Germany

Post by *karlchen »

Hello, jdmarch.

As soon as I have got the chance and time, I will post a screenshot illustrasting what the customfields view "Search Results" looks like here. A screenshot may ease undertanding a lot.

The unremovable EXT column does not pollute anything here. All it will hold here is two little dots.

The tc.fullname is used to make sure that filename and extension are displayed in the right order, filename first, extension second, without having to insert another column for the extension.

Maybe the crucial factor which decides whether you get what you want or whether you don't when using the view "Search Results" is this setting:
Configuration => Options => Display => Tabstops:
Show file extensions
(*) directly after filename
(_) aligned (with tab)

Extensions are displayed directly after the filename here.

Kind regards,
Karl
User avatar
Lefteous
Power Member
Power Member
Posts: 9535
Joined: 2003-02-09, 01:18 UTC
Location: Germany
Contact:

Post by *Lefteous »

The generic problem here is that only full paths can be unique. When using such a custom column view a secondary sort order is required. TC already has such a mechanism. There should be a way to show the search result not only in a preferable (column) view but also in a useful sort order - of course without manual activity.


2karlchen
works in a satisfying way here
I don't think a workaround can be satisfying. It's really just a workaround.
User avatar
karlchen
Power Member
Power Member
Posts: 4603
Joined: 2003-02-06, 22:23 UTC
Location: Germany

Post by *karlchen »

Lefteous wrote:I don't think a workaround can be satisfying. It's really just a workaround.
Your point of view.

My point of view:
A workaround that does what I want is 100% better than no solution at all. :wink:

Karl
Post Reply