Folder Specific Settings Bugs

[admin]

Found a bug: If you open a folder in the background the FV is not applied. Instead it inherits the view of the currently active folder.

Yes, fixed in next version.

[jacky]

- I go to a folder with a FV that sets a Sort order
- I go to My Computer (or Network Places)
- I go to some folder without FV : Sort order is from the folder with a FV (and so is now new default) instead of being the last used/from default FV (Using XY's automatic default, no actual DFV set)

[admin]

- I go to a folder with a FV that sets a Sort order
- I go to My Computer (or Network Places)
- I go to some folder without FV : Sort order is from the folder with a FV (and so is now new default) instead of being the last used/from default FV (Using XY's automatic default, no actual DFV set)

Yep and fixed.

[jacky]

Couple more bugs for you to crush

- Save FV As : we get a confirmation about overwriting existing FL only if it's not for the current folder

- Trailing backslash: One can create multiple FVs for the same folder using "D:\Folder" and "D:\Folder\" Then, only one of them is active, but the other is still there !! (And may be used, in fact, for example if you remove one, the other just takes over! And I haven't check but maybe it could even be possible that if one doesn't include all settings, they could be loaded from the other one and not DFV, though that might be unlikely as you probably threat the DFV as a special case...)
Actually, it seems the same can be done playing on case (e.g. "D:\Folder" and "d:\Folder") which isn't good either...

[admin]

Couple more bugs for you to crush

- Save FV As : we get a confirmation about overwriting existing FL only if it's not for the current folder

- Trailing backslash: One can create multiple FVs for the same folder using "D:\Folder" and "D:\Folder\" Then, only one of them is active, but the other is still there !! (And may be used, in fact, for example if you remove one, the other just takes over! And I haven't check but maybe it could even be possible that if one doesn't include all settings, they could be loaded from the other one and not DFV, though that might be unlikely as you probably threat the DFV as a special case...)
Actually, it seems the same can be done playing on case (e.g. "D:\Folder" and "d:\Folder") which isn't good either...

The first one is by design.

Okay, I changed it: now case and backslashedness are ignored. So saving "D:\Folder\" as "d:\folder" will now overwrite "D:\Folder\" and rename the pattern to "d:\folder" without asking. Avoids creating duplicates.

[jacky]

The first one is by design.

Noted.

Okay, I changed it: now case and backslashedness are ignored. So saving "D:\Folder\" as "d:\folder" will now overwrite "D:\Folder\" and rename the pattern to "d:\folder" without asking. Avoids creating duplicates.

So just to be clear : that doesn't apply to patterns, only folder path/name(s), right? Or does it apply to pattern as well when option "Match case" is disabled ?

[admin]

The first one is by design.

Noted.

Okay, I changed it: now case and backslashedness are ignored. So saving "D:\Folder\" as "d:\folder" will now overwrite "D:\Folder\" and rename the pattern to "d:\folder" without asking. Avoids creating duplicates.

So just to be clear : that doesn't apply to patterns, only folder path/name(s), right? Or does it apply to pattern as well when option "Match case" is disabled ?

I had the same thought and I decided to skip case ignoring! Don't want to be too smart: If the user changes the case of pattern I assume he will have his reasons.

Here's the change log entry:

Code: Select all

    * FVS | Save Folder View As...: Now the backslashedness of the 
      pattern are ignored when checking for any existing patterns. So 
      saving "D:\Folder\" as "D:\Folder" will now overwrite "D:\Folder\" 
      and rename the pattern to "D:\Folder" without asking. Avoids 
      creating (pseudo-)duplicates.
      Note that backslashedness of the pattern is irrelevant anyway, but 
      changing the capitalization can be relevant in wildcarded patterns 
      when Match Case is enabled. So you are allowed to create a dupe 
      when you save "D:\Folder" as "d:\folder" because there may be a 
      good reason behind it.

[jacky]

I had the same thought and I decided to skip case ignoring! Don't want to be too smart: If the user changes the case of pattern I assume he will have his reasons.

hmm... okay, your choice

I'm not sure about this, because in Windows world d:\folder ; D:\Folder and D:\FOLDER are all the same unique folder, there's no way around it. So I can't really see a point to have two FV with different case (whether or not Match Case is used) because they can't possibly refer to different folders. (Well, I guess they "could" for some USB drive or something, but I doubt that's ever gonna be a case that will really occur...)

The only thing I could see is when using patterns, because maybe one could use "*\foobar" for something, but "*\FOOBAR" for something else as all uppercase would indicate a state or something...

Anyways, I'm not sure this is such a good idea to allow dupes that way, especially because XY will use "D:\MyFolder" when I create a FV from there, but if I typed it in because I create it from another folder, or in a multiple folders ( | ) list, then I might be likely to use "d:\myfolder" (and even if the autocomplete kicks in (which doesn't happen for multiple folders) the drive letter is on me...

My point being, to answer to your "So you are allowed to create a dupe when you save "D:\Folder" as "d:\folder" because there may be a good reason behind it" ; it might be most likely that there was no reason, because it wasn't even intentional ! And since "Match case" wasn't enabled, one would have logically assume it didn't matter to use "d:\folder" -- but because he forgot there was already a FV for "D:\Folder" he's now perplexed : he created a FV, there's one active, but it's not the one he created. And, if he removes the FV there's still one for that folder!

[admin]

I had the same thought and I decided to skip case ignoring! Don't want to be too smart: If the user changes the case of pattern I assume he will have his reasons.

hmm... okay, your choice

You got it.

The test of time will show how this works out in every day real work. I would assume it's a quite irrelevant pseudo-issue...