New
#261
First, let me say thanks because, well MS dropped the ball big time and you picked it up and helped us all.
Thanks.
but...
[QUOTE=tweaker;953160
Lately I've also been thinking of adding (as an option) the ability to prevent saving when a window is closed by holding down shift while closing. That would not prevent saving when navigating to a new location within the same window though, so I haven't decided yet.[/QUOTE]
While this is a great idea I think it needs to be taken one step sideways. What I mean is that SFF should only save folder position when you hold down shift while closing.
My reasoning is (and I think this holds true for most people I see when dealing with folders) that I make only a few decision as to where I want a folder to open but, like retiredfields, I am constantly shuffling around my open folders depending on the clutter (other open folders and programs) on my desktop.
The logic goes like this:
When a user makes a new folder, the position will be either system default or as defined by SFF's 'Init Defaults From' option.
At this point the user will leave the folder positioned as is and close it or they will customize the position and then they would then have to 'shift-close' to save the folder position. (Note that this customizing of a folder's position only happens infrequently as users don't really think "Is this where I want to position this folder?" every time they close it.)
So, in the course of using a computer (with SFF running) three situations arise:
1 Only one folder is opened and the position probably isn't going to change.
or
2 Multiple folders are opened via the 'save/restore workspace' option in which case 'wanted and expected' workspace is changed only on an infrequent and 'considered' basis.
or (and this seems to be how myself and most people I know handle folders most often, with or without SFF)
3 Folders are opened... then more folders are opened and then you need to move some around to see others. Then some need to be moved yet again because you just opened other folders. This means that users are positioning folders dynamically and the positions are dependent on a temporary desktop folder/program arrangement. Now, logically, if these multiple folders were left in their SFF saved positions or if they got moved back into them, then SFF doesn't need to 're-save' their positions, but that's what it does.
So to me using 'shift-close' to save a folders position (occasionally) seem more efficient in the long run then always saving it and then having me re-arrange temporary folder positions and would create an even more consistent desktop 'folder environment'.
Since I added the ability to disable saving as well as the shift-close functionality (actually it ended up being control instead because shift is already taken by Windows), it seems like a smaller change to make shift-close work in reverse.
I was currently testing the release candidate for the new version, but if it's just a simple change I'll add this aswell for release sometime within the next days.
New version is now up. Change list is added to first post.
--
I added this under "Disable State Recording", just enable the option to show the command in the context menu. There's also an option to reset it back to non-disabled every time the app starts, in case you want that. The other solution to hold down a key (control) while closing is also added if you want to try that.
I don't know why that happens, I can only make guesses, so this may or may not help. I added an option to set a startup delay, try to set that and see if it helps. I would suggest starting with something longer, like 2.5 seconds (2500) or even 5 seconds (5000), and if it does help then you can try reducing the delay a bit again.
The feature made it in. Under Disable State Recording check the "Disable" and "Enable control key modifier to record" options, that will only save it if you press control while closing.
Please add link to download area when new version is available or in context menu.
Shouldn't the ReadMe for the 1.1.4 Ctrl key changes say "folder windows"
instead of just "windows" for what is affected by the database updating
suppressed/allowed by the new functions? Non-Explorer windows, e.g.,
for Excel, IE, Control Panel, etc., don't seem to be affected by the new
functions, but instead their state is always recorded in the database no
matter how the new options are set and Ctrl key is pressed during close
of the window. The tooltips for the SFF options menu do say "folders",
not just "windows in general", and that seems to be the way SFF works in
my few tests. Is there any reason why the new functions are restricted
to just folders instead of applying to more general windows?