Columns Do Not Persist When Changing Folders

Discussion & Support for xplorer² professional

Moderators: fgagnon, nikos, Site Mods

Post Reply
sha.s
Member
Member
Posts: 10
Joined: 2018 Feb 13, 13:52

Columns Do Not Persist When Changing Folders

Post by sha.s »

Hello,

When I add a set of columns to a tab in addition to existing columns, and subsequently click on a folder to go down a level, or go up a level, the new columns are not carried forward. Is that the correct behavior, or is there a setting I need to apply?

Thanks,

Sha S.
User avatar
nikos
Site Admin
Site Admin
Posts: 15771
Joined: 2002 Feb 07, 15:57
Location: UK
Contact:

Re: Columns Do Not Persist When Changing Folders

Post by nikos »

the likely explanation is that you have used custom folder settings in the folder where you changed the columns, therefore the changes won't apply to other folders that get the default mode

if that's the case, try NOT to use custom folder settings except for the few folders you want to see differently. For more information see here www.zabkat.com/blog/settings-headaches.htm
EMathews3
Bronze Member
Bronze Member
Posts: 87
Joined: 2014 Aug 23, 12:54

Re: Columns Do Not Persist When Changing Folders

Post by EMathews3 »

My problem is, after saving that folder's columns to a desktop.ini file, come back later to display that folder, and some columns are wrong. The header shows a different column name, and of course the rows are usually empty because the files don't have that property. Then re-set the columns, re-save the settings for that folder, come back later and the same columns are wrong again. It's like an indexing error because it's consistently the *same* columns being displayed as the same wrong columns.

Looking in Column Sets / Organize, the Description does yes match the columns that are different from what had been previously set. I have to carry two Columns Sets to avoid re-doing the "Select columns..." / "Column customization" and Actions / Folder settings / Save every time it goes wonky. Just pick one or the other entry from Column Sets and then it looks right ... until xp2 restarts or whatever the problem-trigger is.

[Correct column] is swapped with [Wrong column]
"Bit depth" is swapped with "Encryption Status"
"Date taken" is swapped with "Lens model"
"Pages" is swapped with "File version"

szSystemPropsList is set to System.FileFRN.

Don't know how to debug this further on 3.4.0.4 U x64 7/15/2017
User avatar
nikos
Site Admin
Site Admin
Posts: 15771
Joined: 2002 Feb 07, 15:57
Location: UK
Contact:

Re: Columns Do Not Persist When Changing Folders

Post by nikos »

one way this could happen is if you are browsing folders sometimes from libraries and sometimes from normal paths. Libraries slightly change the order of the columns. So you must decide which route you want to take to your folders and stick with it. Otherwise, system columns will get mixed up. xplorer2 [S]tock columns on the other hand will be fine in all situations
EMathews3
Bronze Member
Bronze Member
Posts: 87
Joined: 2014 Aug 23, 12:54

Re: Columns Do Not Persist When Changing Folders

Post by EMathews3 »

Wow, I'll have to watch and see when it happens or not. Yes it seemed like an indexing or off-by-one type of error.

Also that's kind of annoying. Sounds like a bug in Windows 8 Libraries, eh? Something that xp2 and competitors should not have to compensate for. When I navigate manually, I always start from Libraries, except when trying to find a directory that does not have a path to it existing under Libraries. (Not everything is going to be reachable through Libraries, and that's part of the idea).

And of course when using an application's command to "Browse containing folder" or similar, that's gonna go by the standard C:\Whatever addressing and not through Libraries. For example, opening a folder from an indexing utility like David Carpenter's terrific "Everything" at http://voidtools.com

Running this new test is interesting: Open two xp2 tabs, so as to navigate to a folder with a desktop.ini

Code: Select all

Tab one - start with Computer, C:\, FolderOne, FolderTwo:
-> headers are correct, but rows show wrong   values for Bit-Depth and Date-taken.
  
Tab two - start with Libraries, LibraryOne, FolderOne:
-> headers are correct, and rows show correct values for Bit-Depth and Date-taken.
This is a different misbehavior from what I usually see. In the previous reply, the column headers were wrong by surprise, so of course the row values were also wrong.
Last edited by EMathews3 on 2020 Feb 19, 01:54, edited 1 time in total.
User avatar
nikos
Site Admin
Site Admin
Posts: 15771
Joined: 2002 Feb 07, 15:57
Location: UK
Contact:

Re: Columns Do Not Persist When Changing Folders

Post by nikos »

strictly speaking it is a bug that I've been putting off dealing with because to fix it will make browsing slower for everyone, since columns wouldn't be identified by a simple offset number
EMathews3
Bronze Member
Bronze Member
Posts: 87
Joined: 2014 Aug 23, 12:54

Re: Columns Do Not Persist When Changing Folders

Post by EMathews3 »

Here's another unexpected weirdness.

When looking at the same folder through the two tabs, the same files show Modified-Dates that are different by one or two seconds.
User avatar
nikos
Site Admin
Site Admin
Posts: 15771
Joined: 2002 Feb 07, 15:57
Location: UK
Contact:

Re: Columns Do Not Persist When Changing Folders

Post by nikos »

for more consistent results use the [S] stock column whenever available, e.g. for dates
EMathews3
Bronze Member
Bronze Member
Posts: 87
Joined: 2014 Aug 23, 12:54

Re: Columns Do Not Persist When Changing Folders

Post by EMathews3 »

Right, the only reason I mention it is because both tabs show exactly the same columns, including Modified [S], but the date values are all displayed differently between the two tabs for the same files. One tab is through Libraries and the other is through Computer.
EMathews3
Bronze Member
Bronze Member
Posts: 87
Joined: 2014 Aug 23, 12:54

Re: Columns Do Not Persist When Changing Folders

Post by EMathews3 »

Here's a consideration. Could we optionally have child folders respect the desktop.ini that exists in the parent folder? This is basically an alternative approach to implementing the Yes answer to the "Apply the same folder settings for all subfolders?" prompt. As in, achieving the same effect but without copying the INI file to all folders below. The tradeoff would be some extra processing in common cases, and extra time for scanning directories in rare cases.

In the common case of displaying a folder *after* displaying or scanning its parent, xp2 would scan the folder for an INI to use (as it does now). Finding none, it would inherit and use the columns-setting from the previously-displayed parent. The parent's setting would have been recently loaded from an INI in the parent folder, or recently loaded by inheriting the setting from *that* folder's parent. Thus, there would be no need to scan the tree above the current folder.

In the rare case of displaying a folder *starting with* a deep folder, xp2 would have to scan up the tree until finding an INI to inherit and use. When the scan is exhausted but no INI is found, xp2 would use the master columns-setting from "Save settings now".

The goal is to have columns-settings for whole sections of the file system. For example, it would be great if different column-sets could apply to all folders underneath different Library items, regardless of desktop.ini. Yes Windows tries to do this with "Optimize this library for" [General/Documents/Music/Pictures/Video], but xp2 probably supports Windows versions that don't have Libraries.

Is "Save settings now" supposed to work per-layout, or is it only one setting for all layouts (aside from the per-folder desktop.ini) ?
User avatar
nikos
Site Admin
Site Admin
Posts: 15771
Joined: 2002 Feb 07, 15:57
Location: UK
Contact:

Re: Columns Do Not Persist When Changing Folders

Post by nikos »

each layout is a registry (or INI) section, saving the window settings. So each "save settings now" saves the current layout (or more if 2 or more layouts happen to be open at the time)

as for your INI inheritance idea, everything is possible, but what would be the advantage? Desktop.ini is a tiny file so the waste in storage will be more than made up by efficiency in reading folders
Post Reply