Blueprints of pane.ini + branch view question

[Marco]

Don, would you mind sharing some info about the structure of pane.ini?
I ask because since 13.70.0111 my tabsets are misbehaving. Since I edited them manually in a text editor long ago I suppose I somehow screwed them, and even if XY pre-0111 accepted them, after-0111 parses them slightly differently. So I'd like to fix them now.

Secondly, a related problem. Till last week, whenever I clicked branch view my list was sorted by path and (secondly) by extension. Now no more, all I see is the Name column (still because of the corrupted pane.ini's). However I tried with a fresh session too, and while I see all the columns, I'm no longer able to set a branch view so to remember its sorting columns (path and extension). What am I missing?

[Marco]

Gents, could you please help me?

I'm trying to have XY remember to always sort by path and secondarily by extension in a branch view. Here are my steps on a fresh 13.70.0123:
1. Go to a folder which has subfolders and files
2. Branch view it by clicking the correct button on the toolbar
3. Sort by path and secondarily by extension by clicking on the column headers
4. Right click on the column headers and select "Define Current Column Layout as Default"
5. Click OK in the following popup

Now, if I go to another folder, in another tab, and perform a BV, the column layout is not remembered. Why so?

[admin]

After Extra Tags... (soon).

[Marco]

So it's a bug or I'm missing something? I ask because I had no problems whatsoever before Extra Tags.

[TheQwerty]

Now, if I go to another folder, in another tab, and perform a BV, the column layout is not remembered. Why so?

I think this is a bug in that XY is incorrectly writing the Sort key(s) within pane.ini.

I believe...
Within pane.ini each list mode has a section.
The Sort key is a ;-delimited list of the applied sort columns in the form: Primary_Sort_Column,Direction;Secondary_Sort_Column,Direction

From a fresh copy of v13.70.0123 execute:

Code: Select all

::SortBy 'Name', 'a', 0;SortBy 'Type', 'd', 1;SaveSettings;

If you look at the corresponding section of pane.ini you'll likely see its sort key has a value of Name,a;Name,a when it should be Name,a;Type,d. In fact, if you modify the key to be the latter and restart XY it should apply the primary and secondary sorts correctly.

My guess Don accidentally broke writing the sort key when adding support for the new Extra Tag columns.
And will likely fix it before Extra Tag is released in stable.

----

As for blueprints of pane.ini, this is my best guess for v13.70.0123, but I wouldn't be surprised to see changes until Extra Tag and Shell Columns are complete...

Code: Select all

[General]
LastVer = Last version of XY to write pane.ini.
Location = Location of the active tab.
IDDefaultTab = Tab index of the pane's default tab.

[List<Mode>]
Sort = ;-delimited list of Column Name(s) and Direction(s) to sort by. (Name,d;Type,a)
Num= Not sure.
Style = Corresponds to the Customize List selections OR-ed.
View = Selected List View.
Date = Selected Format
Time = Selected Format
Age = Show age toggle.
Day = Show day toggle.
Columns = List of columns followed by their width, those starting + are visible.

[Tabs]
Version = Current version of INI file.
LastTab = Previously active tab.
MRU= MRU used order of the tabs (A is left-most tab.)
Count = Total number of tabs.

For each tab... (# is each tab's index)
I# = Tab's index.
C# = Tab's user-specified caption.
H# = Tab's home location.
D# = Location
A# = Current Options and Column Settings (this is a complicated one to interpret and seems based on the tab's custom List View, Customize List options, and Columns).
M# = A# at the time home was set, and restored to A# when going home.

[History]
Count = Number of items.
Cur = Current position in history.
# = Location
#t = Tab with corresponding # location in its history.

[Marco]

A huge thank you, TheQwerty.

Code: Select all

A# = Current Options and Column Settings (this is a complicated one to interpret and seems based on the tab's custom List View, Customize List options, and Columns).

Yep, the most obscure one. Anyway, there's definitely something broken in the column management, settings are lost when changing tabs. It's a pity because I have to stick to the pre-extra tags build.

[TheQwerty]

Code: Select all

A# = Current Options and Column Settings (this is a complicated one to interpret and seems based on the tab's custom List View, Customize List options, and Columns).

Yep, the most obscure one.

I spent a lot of time trying to understand that one when I built this script (not sure it even still works).

I didn't keep my notes, and it might have changed anyhow, but according to that script I determined it was tab-separated (duh) and that token:
4 was the sort order.
9 was the view mode.
14 was the list style.
Clearly token 3 is the columns configuration.

I would guess it's a tab-separated value consisting of all the fields in the List<mode> sections, but for the specific tab.

[admin]

Did not have time yet to look into it, but note this: In v13.70.0123 I fixed something related to reading and upgrading pane.ini from the pre-Extra-Tags-era. Please get your original files from your pre-Extra-Tags-era backup and try upgrading (and changing tabsets) with v13.70.0123.

The sort issue I will look into later tonight.

[admin]

From a fresh copy of v13.70.0123 execute:

Code: Select all

::SortBy 'Name', 'a', 0;SortBy 'Type', 'd', 1;SaveSettings;

If you look at the corresponding section of pane.ini you'll likely see its sort key has a value of Name,a;Name,a when it should be Name,a;Type,d. In fact, if you modify the key to be the latter and restart XY it should apply the primary and secondary sorts correctly.

My guess Don accidentally broke writing the sort key when adding support for the new Extra Tag columns.
And will likely fix it before Extra Tag is released in stable.

Correct analysis in all parts. Fix comes tonight...

[TheQwerty]

Well v13.70.0126 fixes the bug of storing the secondary sort properly.

It also seems to restore both sorts when performing a search.
However, branch view does not appear to restore its sort order and instead reverts to Name,a (or inherits the sorting from an active Search Results tab).
Worse though is that since BV is just a fancy find, when it changes the sort order it also blows away the user's desired sorting for search results.



In summary, a bug is fixed but not the one biting Marco.

[admin]

OK, I think I got it. BV will now default to sort by Path again.

However, secondary sort by extension?? I'm not sure if this ever worked.
1. "Define Current Column Layout as Default" only works together with "Restore Column Layout from Default".
2. Sort Order has never been saved along with this.

[TheQwerty]

OK, I think I got it. BV will now default to sort by Path again.

The bug isn't in what it defaults to but that it doesn't restore the sort order from ListFind - although the argument could be made that BV should become its own list mode with settings separate from ListFind.

Run this from a fresh XY, it might better demonstrate the problem:

Code: Select all

"Test"
 // Set ListBrowse.Sort to Name,a;Type,d.
 goto <xy>;
 SortBy 'Name', 'a', 0;
 SortBy 'Type', 'd', 1;
 Status 'Sorted by Name,a;Type,d';

 // Enable Branch View.
 // This should use the default sort order of ListFind/BV.
 #311;   //View | Views | Branch View
 Echo "What's the sort?<crlf>It should be the default for BV which was Path,a";

 // Sort BV by Name,a;Ext,d.
 // By extension this should change ListFind's sort as well.
 SortBy 'Name', 'a', 0;
 SortBy 'Ext', 'd', 1;
 Status 'Sorted by Name,a;Ext,d';

 // Disable BV, returning to ListBrowse.
 #311;
 Echo "What's the sort?<crlf>It should have restored the order from before BV which was Name,a;Type,d";

 // Enable BV, it should retain Name,a;Ext,d but doesn't.
 #311;
 Echo "What's the sort?<crlf>It should have restored the order from last BV which was Name,a;Ext,d";

 // Disable BV.
 #311;

 // Enter ListFind.
 // When we changed the sort in BV it "should" change the sort here.
 #261;   // Edit | Find Now
 Echo "What's the sort?<crlf>As BV and ListFind share settings this should have the restored order from last BV which was Name,a;Ext,d";

 // Change Sort order of Search Results to Name,a;Size,d.
 SortBy 'Name', 'a', 0;
 SortBy 'Size', 'd', 1;
 Status 'Sorted by Name,a;Size,d';

 // Enable BV (with active Search Results tab)
 // It correctly sorts by Name,a;Size,d.
 #311;
 Echo "What's the sort?<crlf>As BV and ListFind share settings this should have the order set in Search Results which was Name,a;Size,d";

EDIT: Corrected script and made the echo dialogs a little clearer.

[Marco]

I'm back online
Thank you both for the support, I confirm what TheQwerty says: the sort order of BV is still forgotten (but all the other ones are remembered).
Don, secondary sort worked in BV too pre-extratags, I was an heavy user of that.

PS: also the Recycler Bin view seems affected by the bug.

[admin]

OK, I think I got it. BV will now default to sort by Path again.

The bug isn't in what it defaults to but that it doesn't restore the sort order from ListFind - although the argument could be made that BV should become its own list mode with settings separate from ListFind.

Run this from a fresh XY, it might better demonstrate the problem:

Code: Select all

...

1) I tried your script with a fresh version of 13.70.0100 (= pre Extra Tag) and it does not behave as the script wants it to behave.
2) I tried your script with a fresh version of the current beta (here, one better than yours) and it does not behave as the script wants it to behave.

The script behaves 100% identical in both versions. So I guess I fixed it, but the script has a bug.

[TheQwerty]

The script behaves 100% identical in both versions. So I guess I fixed it, but the script has a bug.

The script only attempts to demonstrate what a user might do and the echo boxes show what the user might expect the sort order should be at that time.

To fix the "issue" the sort order in the list should match that shown in the echo boxes.

What the script is attempting to demonstrate is that:
1) If the active tab is not a search results tab > entering branch view will use some default sort order.
2) Changing the sort order in branch view, exiting branch view, and then returning to branch view will return to the default sort order.
3) If the active tab is a search results tab > entering branch view will adopt the sort order of the search results tab.

This is not entirely demonstrated in the script, but it is true.
4) Customizing the sort order in a search results tab, returning to browse mode, performing step 1 or 2, and then performing a search will result in the search results tab forgetting the user's defined sort order and instead using the default as set by BV.


Marco, can you run it and verify that the script matches your expectations?


EDIT: This might not be an issue with XY, but with our own expectations. Though that just means instead of a bug report Marco has a feature request.