DO12 - Save Folder Format bug when invoked from SET SAVEFORMAT cmd

[kevinram]

The new SAVEFORMAT is well designed and a big step towards reducing the complexity of persisting folder formats.
I don't think anyone has reported this bug yet, and I could only find one thread that reported a bug related to the new SAVEFORMAT dialog. [url]DO12 - Folder Options | Save... display update error]. But that bug took a different path to invoke the SAVEFORMAT dialog. The bugs I'm experiencing only happen in the context when invoked from the new SET SAVEFORMAT cmd.

Bug #1

Scenario 1A
Here are the steps to reproduce the Save Format Dialog bug I'm experiencing.

#1 - I change the columns displayed in the folder "Opus Text Help", and I'm ready to save them.

#2 - I invoke the Save Format dialog using my global hotkey \S, which runs the cmd SET SAVEFORMAT
RESULT: [BUG] I try all the options in Save Format dialog, and none of them save the format.

Scenario 1B

Here are an alternate set of steps to reproduce a scenario where there is no bug in the Save Format dialog. In this scenario, I've made no additional changes to the folder "Opus Text Help" used to produce the bug above. I also haven't navigated to a different folder tab, so the tab state should be identical.

#1 - I use a different global hotkey \E, which runs the cmd PROPERTIES FOLDEROPTIONS

#2 - I invoke the Save Format dialog by clicking the Save button

RESULT: [No bug] All of the functions work as expected, and formats are saved correctly.

Observations about Bug #1
There is one major difference I've noticed in the Save Format dialog depending on how it is invoked: The file path. In Scenario A, where the Save Format dialog does not work, only the parent folder name is listed for "Save Format For this folder".

Bug #2 - Favorite name

Scenario 2A - What works
In Scenario 1B, when a full path is listed, the name given to the Favorite is displayed correctly in the Folder Formats Prefs page.

2A1 - xTest2 typed into Favorite box

2A1 - Global hotkey /M used to run cmd Prefs PAGE=folderformats, and favorite xTest2 listed as expected
Result: [No Bug]

Scenario 2B - What doesn't work
In Scenario 1A, when just the folder name is listed, and you select Favorite and give it a name, the Favorite is saved. But the name typed into Save Format dialog does not get saved. Instead, the Favorite shows up on Folder Formats Prefs page without any name.

2B1 - xTest1 typed into box

2B2 - Result [BUG] xTest1 shows up as blank entry in Prefs. I know it's X1 based on columns matching.

Notes about Test Data

Note 1
In Scenario 1B, If I manually rename the tab, and run SET SAVEFORMAT again, the parent folder name is still listed. So it's unrelated to the tab name.

Note 2
In Scenario 1A & 1B, the folder path tested was constructed using a symlink, which in turn pointed to a junction, which finally pointed to the file in C:\Storage. (A virtual path system that lets me sync Opus Alternate Data Streams , Aliases, Status Icons, etc, between machines by abstracting hard coded physical paths. ) I tested again using the direct path to the folder used for test 1A, and the results were exactly the same. Here is test 2A using the direct C:\ drive path, with the link chain displayed below.

[Jon]

Thanks for the report!

I can confirm #2 (favorites) and this will be fixed in the next update.

I'm unable to reproduce #1 (other than the difference with the display of the folder name in the save dialog, which is only cosmetic). When I try this here (even with a softlink->junction->folder) it saves the format correctly.

What do you see in Preferences after running the command and saving the format this way? Does it save anything at all?

[kevinram]

You are correct. #1 as I described it is not a bug. But, I found a new bug. And this time I reset all my state, so if I waste your time chasing down something that isn't broken, I'll go back to being a community observer.

Also, if you have time to read the TL;DR, I describe a weird edge case on how to recreate Scenario #1, but not sure it's worth your time. It turns out I made an assumption on how !factory worked.

Bug #3
Folder format is not removed using either SAVEFORMAT variation:

Set SAVEFORMAT=clear
Set SAVEFORMAT=folder,clear

TL;DR
Prior to SAVEFORMAT being introduced, I used SET FORMAT =!factory to "clear" a folder format. Before I implement a command, I generally do a before/after diff of the /dopusdata folder to get an idea of how state is changed. My initial test of !factory made no changes to any XML files. Thus, I assumed something in the program files core logic kept track of the rules to apply !factory, and I assumed !factory == not format path binding.

Since then, I've discovered that !factory actually works very differently. If !factory is run in context of a Lister displaying a folder that already has its path bound to a format, !factory behaves differently. If a path binding exists, !format does not remove the binding. Instead, it actually updates the binding with the XML elements associated with the '!factory' template.

The reason I reported a bug in Scenario #1 was that I had reset the subfolders using !factory. I assumed reset to factory meant 'null' path association. Thus, The SAVEFORMAT=Folder cmd does work as advertised, because the subfolders arg does not override subfolder paths bound to formats. Since I had used !factory, and my UI was displaying the 'factory' format for each subfolder, I assumed no paths were bound. Granted, you mentioned looking at the Folder Prefs Paths. If I had just expanded that node, I would have not reported Scenario #1. I apologize.

Not suggesting !factory should change. It's an advanced edge case. Just FYI.

[kevinram]

Minor language change: I assumed !factory == "no format path binding shall exist in Folders.off"

[Leo]

Set FORMAT=!factory resets the format in the current folder tab only.

It does not save anything to disk or affecf any other windows, folders or tabs. (Unless you then save the tab or window, or save the format to the folder, which are separate actions.)