ShellFolderFix - Manage folder window positions/size

[tweaker]

I want to suggest a feature: like sizer of brianapps, i want to set some default sizes to apply to the windows (right click on windows border)...

I can look into it, allthough I suspect it would have some technical requirements which differ too much from the current functionality. Keep in mind that this app only deals with folder windows, unlike Sizer which works on all apps. I take it Sizer doesn't work on win7?

The program doesn't seem to work for me, not in the way it should at least. For Save/Restore workspace and when it starts at Windows start it restores folders at random positions on the desktop (sometimes with weird sizes), but when I open and close the program without restarting Windows it seems to restore the folders just right. I tried both 64 and 32-bit versions (without installer), also tried the /portable switch - no luck, except that 32-bit version works more strange: with the first using of Load Workspace option it restores folders at random places, and when I click Load Workspace again it does nothing but flashing folder buttons on taskabar. I can provide more details, including the database file and screenshots if it helps solving the problem. Just tell me if I should post them here or send directly to you. I have Polish version of Windows 7, could that be a reason for the problem? (However, none of the opened folder titles contained polish national characters when I performed the tests).

If you use 64bit windows then the 32-bit version of the app can never work as it should (and vice versa), so there's no need to involve that for testing.

For some reason it appears that the app doesn't receive events for tracking folder windows (when starting the app it works because it actively scans for open windows and doesn't rely on event notifications). One possible reason could be that some other (badly written ) app is gobbling up the events and not passing them on like they're supposed to. Do you have any other similar app running or other shell/explorer extensions? Or maybe running Window Manager too?

 

[kazink]

For some reason it appears that the app doesn't receive events for tracking folder windows (when starting the app it works because it actively scans for open windows and doesn't rely on event notifications). One possible reason could be that some other (badly written ) app is gobbling up the events and not passing them on like they're supposed to. Do you have any other similar app running or other shell/explorer extensions? Or maybe running Window Manager too?

Well, the only app I have that could mess with this, as I think, is Classic Shell, so I have uninstalled it, created a new user for testing and disabled antivirus (NOD32) just to make sure. There was no other software (including window managers) running in background other than touchpad driver and antivirus (I didn't want to remove them from autostart, but I can try if you think that may help).
I think it's very unlikely that the events could cause this (or at least it's not the only source), because of the following observations (I'm not a Seven expert, but I know what messages are ):
1. I click Save Workspace, then Restore Workspace - widows get placed in random positions. I click Restore Workspace - again windows get placed in random positions different from the previous positions. Another click and they get different positions again. If it was for messages, I think they should get always placed at the last positions that made it into the database (or not moved at all in case no position has been stored for particular window yet).
2. The same randomness applies to the case when the app starts with the system, even if I choose "Save database now" or close the app before rebooting, only sometimes it manages to restore the windows properly (but it happened once or twice only - it seems random too).
3. When browsing through folders it works perfectly fine - when I use the "When navigating to new location: Update folder" option, the window sizes and positions are updated as they should to the last values they had.

I'm still thinking about the case in point 2, that it puts windows in random positions even if I manually close the app before restarting the system. This is strange, because this should be technically the same case to when I restart the app manually without restarting the system. I have checked it and the only difference is that that the app is started before the folder windows appear on the desktop. if I then close the app and run it again the windows will get updated correctly. I though that it might be that the app couldn't properly detect opening the last folders by Windows Explorer, but I see that the "Restore last folder windows on login" option in the Windows' folder options is disabled, so I'm confused. It seems that ShellFolderFix restores the windows properly when started manually, but not when started automatically with the system (using the built-in auto-start option).

Just checked: when I disable built-in autostart and manually add the app to the Autostar folder in the Start Menu it restored the folders properly (it didn't work when I last tried it), so the problem is worked around. But it would be better to have the regular autostart and workspaces working .

 

[jr1421]

From the mini-FAQ:
"Q: My view layout ... settings are not properly restored for folders, is something wrong?
A: No, it works as it should. Currently ShellFolderFix does not affect ... layout ..., even though I'd like to add support for it in future if possible. Only window position and size are affected/restored."

Any updates on when/if this feature will be implemented in the future? Note, I'm not talking about "view" settings, such as list or details. I'm talking about layout, under organize->layout. I don't need every folder to have the details pane & navigation pane, but I'd prefer not to turn them off for every folder. I hope this can be made possible in future releases of shellfolderfix. Even if not, thanks so much for making this software available.

Sigh...microsoft, why must you always take two steps back to take one forward?

 

[tweaker]

I think it's very unlikely that the events could cause this (or at least it's not the only source), because of the following observations (I'm not a Seven expert, but I know what messages are ):
1. I click Save Workspace, then Restore Workspace - widows get placed in random positions. I click Restore Workspace - again windows get placed in random positions different from the previous positions. Another click and they get different positions again. If it was for messages, I think they should get always placed at the last positions that made it into the database (or not moved at all in case no position has been stored for particular window yet).

...

Just checked: when I disable built-in autostart and manually add the app to the Autostar folder in the Start Menu it restored the folders properly (it didn't work when I last tried it), so the problem is worked around. But it would be better to have the regular autostart and workspaces working .

To be more specific, it doesn't use normal windows messages but a windows hook. Every registered hook (by an application) is responsible for passing on a received "event", a badly/nasty written app could omit doing that and breaking other apps.

Restoring a workspace also relies on receiving events for each restored windows so that it sizes/positions it correctly right after it's opened. Should it for some reason fail to receive an event, the restored window would end up at a random size/pos like you describe. In any case, another app is not the issue here since you say normal usage works. I was under the wrong impression that it never worked.

I had some problems with that when starting up windows when the windows option to restore windows was also enabled, which I found a solution for that appeared to work (as in I haven't had any issue for months now). That shouldn't affect restoring workspaces though, so that part is a bit confusing. Not sure at the moment what the problem could be.

From the mini-FAQ:
"Q: My view layout ... settings are not properly restored for folders, is something wrong?
A: No, it works as it should. Currently ShellFolderFix does not affect ... layout ..., even though I'd like to add support for it in future if possible. Only window position and size are affected/restored."

Any updates on when/if this feature will be implemented in the future? Note, I'm not talking about "view" settings, such as list or details. I'm talking about layout, under organize->layout. I don't need every folder to have the details pane & navigation pane, but I'd prefer not to turn them off for every folder. I hope this can be made possible in future releases of shellfolderfix. Even if not, thanks so much for making this software available.

Nothing new on that yet I'm afraid. Too much other stuff to do, and not enough time

 

[jr1421]

Nothing new on that yet I'm afraid. Too much other stuff to do, and not enough time

No problem - thanks for letting me know

 

[kazink]

To be more specific, it doesn't use normal windows messages but a windows hook. Every registered hook (by an application) is responsible for passing on a received "event", a badly/nasty written app could omit doing that and breaking other apps.

I have some (little) experience with hooks too, so I know what you're talking about

Restoring a workspace also relies on receiving events for each restored windows so that it sizes/positions it correctly right after it's opened. Should it for some reason fail to receive an event, the restored window would end up at a random size/pos like you describe. In any case, another app is not the issue here since you say normal usage works. I was under the wrong impression that it never worked.

And the winner is... Classic Shell, unfortunately . Actually, only the Classic Explorer part. I have installed it again (the newest 1.9.6 RC version), and then SFF started to 'randomize' windows restoring while it was either closed/run manually or run by the shortcut in the Autostart folder. That's why it seemed the app wasn't working good at all before. I see the author of Classic Shell is registered here too. It would be nice if you two get in touch to solve the problem on whichever side it is .

I had some problems with that when starting up windows when the windows option to restore windows was also enabled, which I found a solution for that appeared to work (as in I haven't had any issue for months now). That shouldn't affect restoring workspaces though, so that part is a bit confusing. Not sure at the moment what the problem could be.

Based on what you said I have made more discoveries:
1. The app is working when put in the Start Menu -> Autostart folder manually. I thought it was working always, but now it seems it's not true. It works good only if the system manages to restore the last folder windows before ShellFolderFix starts. If it SFF starts before or during restoring the windows, their positions get randomized.
2. Closing and running SFF manually doesn't close and reopen existing folder windows, it just sets positions <- this works good (not counting the Classic Shell issue).
3. Saving and restoring the workspace do closes all the existing folder windows and recreates them already in target positions <- this seems to work improperly.

I suppose in case 1 SFF decides which method (from case 2 or 3) to use depending at which point it is started, that's why it sometimes works good and sometimes bad. And I suppose when using autostart option in SFF the program is always started before system folder windows restoring, that's why the problem always occurs then.

If you have an idea for a program (or a test-mode SFF version) collecting information that could help you find the source of the problem, I would be happy to run it on my machine and/or perform some more specific tests. I'm so desperate to have this functional .

 

[johngalt]

1. The app is working when put in the Start Menu -> Autostart folder manually. I thought it was working always, but now it seems it's not true. It works good only if the system manages to restore the last folder windows before ShellFolderFix starts. If it SFF starts before or during restoring the windows, their positions get randomized.
2. Closing and running SFF manually doesn't close and reopen existing folder windows, it just sets positions <- this works good (not counting the Classic Shell issue).
3. Saving and restoring the workspace do closes all the existing folder windows and recreates them already in target positions <- this seems to work improperly.

I suppose in case 1 SFF decides which method (from case 2 or 3) to use depending at which point it is started, that's why it sometimes works good and sometimes bad. And I suppose when using autostart option in SFF the program is always started before system folder windows restoring, that's why the problem always occurs then.

If you have an idea for a program (or a test-mode SFF version) collecting information that could help you find the source of the problem, I would be happy to run it on my machine and/or perform some more specific tests. I'm so desperate to have this functional .

Hmmm. WinPatrol has a delayed start method that allows you to delay how long an app will autostart - for example, I have several IM clients running, so to help speed my desktop and limit their interference I have delayed them all by a minimum of 1 minute, and each loads in a 30 second increment after the last, up to 2.5 minutes.

End result - my IM clients load, but after I am already running around doing things like loading apps / Thunderbird, etc.

I wonder if this can be applied to SFF once you place it in AutoStart, so that you could *force* it to wait until after every folder loads to then start running?

 

[Ivo]

And the winner is... Classic Shell, unfortunately . Actually, only the Classic Explorer part.

Can you try to disable the Classic Explorer features one by one to see if you can find which one is causing the problem? I am away from home and can't do anything till the end of the month aside from posting here.

 

[kazink]

And the winner is... Classic Shell, unfortunately . Actually, only the Classic Explorer part.

Can you try to disable the Classic Explorer features one by one to see if you can find which one is causing the problem? I am away from home and can't do anything till the end of the month aside from posting here.

This is very strange, but after installing CS again to make the tests the problem has gone. I tried changing several settings, including restoring it to state when it caused problems before, and it doesn't cause problems any more. I suppose I made a mistake, and the problem was caused by something else or it was a random issue (I wouldn't be surprised if that was the case ).

 

[johngalt]

What if this happened:

You installed CS, and then rebooted and a Windows Update hosed SFF....

You then installed CS again, which actually reverted the changes made by said Windows Update, and presto, it works again?

 

[kazink]

johngalt, I don't think so. I installed CS, checked both autostart and manual start of SFF, then uninstalled CS (this should have reverted the changes), and wrote the post here. Then I installed CS again (this should have made the changes again) and was very surprised that manual start of SFF was working good (didn't check autostart because it wasn't reliable anyway). A reboot or two was also issued somewhere on the way. Why would Windows Update tamper with SFF in the first place?

 

[tweaker]

Based on what you said I have made more discoveries:
1. The app is working when put in the Start Menu -> Autostart folder manually. I thought it was working always, but now it seems it's not true. It works good only if the system manages to restore the last folder windows before ShellFolderFix starts. If it SFF starts before or during restoring the windows, their positions get randomized.

There may very well be some issues there, as I mentioned (I think) I had issues during that short phase when windows restores folders on startup at the same time as SFF. I added a delay in SFF to work around it, this delay is only active if the auto-start shortcut contains the /autostart command-line option.

It's possible that the delay is too short if the computer is a bit slower or there's a lot going on during startup. Another solution to avoid this is to disable the windows option to restore folders on startup, and let SFF handle that (or vice versa). Granted that wont restore certain windows like control panels, my computer etc.

If this was the only issue I could add some longer delay option, but since you have more weirdness going on I'll wait until that (hopefully) can be resolved and see if this issue remains.

2. Closing and running SFF manually doesn't close and reopen existing folder windows, it just sets positions <- this works good (not counting the Classic Shell issue).

That's intended behavior, so nothing strange there. Manually starting SFF will only "aqcuire" existing windows and make sure they are at desired pos/size.

The /autostart command-line option is the one that tells SFF that it should behave like windows is starting up. However it will only open new windows that it thinks are supposed to be open, and let any other windows remain open, this so it plays nicely with windows own restore-folders-on-startup which can restore other open windows (control panels, my computer etc.) that SFF doesn't.

If you wouldn't want that behavior then disabling the windows option to restore windows at startup will give you the same results as if SFF closed them all before restoring.

3. Saving and restoring the workspace do closes all the existing folder windows and recreates them already in target positions <- this seems to work improperly.

Restoring a workspace is the only time SFF will close all windows and open new ones, when it works as it should.

If you have an idea for a program (or a test-mode SFF version) collecting information that could help you find the source of the problem, I would be happy to run it on my machine and/or perform some more specific tests. I'm so desperate to have this functional .

If I can up with something specifically to test then I can make a debug version. The issue is still a bit fuzzy for me though

-

So to recap, when exactly is there a problem now. Only during windows startup? If yes, then you could try to disable the windows option "Restore previous folder windows at logon" if you have that enabled, and see if anything improves. Also make sure the SFF shortcut contains /autostart, in case you manually created a shortcut.

If you have other issues, that happen even when startup works correctly, could you make a quick list with those again. I lost the overview of exactly what isn't working


I don't think Classic Shell does anything badly like gobble up events, if it is some window creation timing (like during windows startup) then it's possible that the additional processing from Classic Shell might make it more prone to "miss-timings" but not really its fault. But I need to be a bit clearer on exactly what things aren't working in SFF before speculating more, and maybe having a quick look at the Classic Shell source for possible conflicts.

(I think several others are using SFF and Classic Shell, and it also works for you sometimes, which is another indicator for some timing thing. But again I need to figure out if it's a timing issue that only stems from something going wrong at windows startup, or if it happens all the time for you.)

 

[kazink]

OK, I was too confused about the results I was getting before, so I have remade all the test cases providing (almost) identical startup environment.
Classic Shell was uninstalled, DropBox was unlinked and removed from autostart (only from case 5 up, just to test if that's not it's fault). I had no apps running at startup other than NOD32, drivers and Windows Defender window appearing every time, only to tell me that everything is fine (because it started appearing on it's own one day, and I don't know how to get rid of it without disabling the Defender ).
SFF folder restoration at logon was always enabled, however, from the tests it seems that the function is disabled when there is no /autostart switch present.
Every case have been tested at least 3 times.

1. Autostart with /autostart, windows folder restoration enabled - sometimes works good, and sometimes bad. I can see the programmed delay (windows show up and then get moved to new positions (sometimes correct, and sometimes not), but not always. In some cases (about 20%) the windows show at random positions and stay there. The program startup time is variable - sometimes its icon shows before the windows start to appear, sometimes in the middle of it, and sometimes after. The startup time doesn't seem to have influence on the functioning.
2. Autostart with /autostart, windows folder restoration disabled - always bad. What's interesting - after system start I can restart SFF manually to get all windows positioned correctly .
3. Autostart without any switches, windows restoration enabled - almost always bad. The windows appear already at random positions and never get moved. There are some interesting rare cases where one or two windows get opened just with the SFF icon appears (or maybe slightly before - it's hard to tell), and these are positioned correctly, then it's a one second delay, and the remaining windows appear at random positions.
4. Autostart without any switches, windows restoration disabled - doesn't restore any folders.
5. Bonus - Autostart with /autostart, windows restoration enabled, but SFF restoration disabled. Similar to 3 (windows never get repositioned after they appear), but correctly positioned windows appear more often (about 40% of cases, usually 1~3 of 4 previously opened, sometimes none, all of them - never).
6. Save/restore workspace - just like point 3 - some windows get positioned correctly, other randomly. Usually 2~3 of 4 are correct, sometimes none, never all of them.
7. Manual restart - almost always correct, though sometimes one of the windows gets positioned not according to its last position, but maybe an older one (though not randomly, I think).
8. Manual folder opening (from desktop shortcuts for example) - always working good.

 

[tweaker]

2. Autostart with /autostart, windows folder restoration disabled - always bad. What's interesting - after system start I can restart SFF manually to get all windows positioned correctly .

I don't think that's too strange. The timing issue I've mentioned is in relation to SFF resizing/moving a window very shortly (or simultaneously for the human eye) after the window is created. When you start manually there is no window creation happening, SFF only scans through open windows and repositions them.

Whereas during windows startup and workspace restoration there are a number of windows being created and then instantly updated by SFF.

When you manually open folders it's just one at a time, so if it's the timing thing that might be the reason it isn't happening because it's not quite as "stressful".

For some reason it appears your setup is a little more sensitive to this (could be performance related of the computer). I'll have to think a little about it and see if I can come up with some workaround to try in a debug version for you.

 

[kazink]

Whereas during windows startup and workspace restoration there are a number of windows being created and then instantly updated by SFF.

When you manually open folders it's just one at a time, so if it's the timing thing that might be the reason it isn't happening because it's not quite as "stressful".

For some reason it appears your setup is a little more sensitive to this (could be performance related of the computer). I'll have to think a little about it and see if I can come up with some workaround to try in a debug version for you.

Ok, so I did the "stressful" test: created a bat file that opens 10 folders. I have made sure SFF had correct positions of the folders by closing and running SFF - it didn't change the positions (had to repeat it two times, because it didn't remember them all at the first time). Then I closed all the folders and executed the bat file. The first 4 folders (and one somewhere in the middle) opened at good positions, and the rest appeared in the lower right corner, 70% off the screen (all at the same position). This means that SFF has problems when processing many folder openings happening at the same time (which occurs for workspace restoration feature and at the system start), or that it didn't store positions for those folders (which is unlikely). I don't think it has anything to do with the computer performance. It is dual core 2,1 GHz and doing more or less nothing at the time of making the test. In addition, this test was made long after system have started, so startup "business" couldn't influence it.

Just an idea: when I was doing something with Windows hooks I stumbled on an information (maybe in MSDN, it was long time ago, so I don't remember) that if the hook processing code takes too long time (counted in milliseconds IIRC) Windows will just abort the hook procedure it to avoid overall system hangup. But I'm not sure if that applies to all hooks (or only low-level ones), and to Windows 7.

 

[tweaker]

This means that SFF has problems when processing many folder openings happening at the same time (which occurs for workspace restoration feature and at the system start)

Just an idea: when I was doing something with Windows hooks I stumbled on an information (maybe in MSDN, it was long time ago, so I don't remember) that if the hook processing code takes too long time (counted in milliseconds IIRC) Windows will just abort the hook procedure it to avoid overall system hangup. But I'm not sure if that applies to all hooks (or only low-level ones), and to Windows 7.

From what I could see it's not really SFF that has the problem, it's windows. When it calls the hook that a shell window has been created, the internals of the folder window is not completely created yet or not fully registered in explorer or whatever, which seems that in some stress situations could cause issues. I only had those problem in earlier versions though, after changed handling a bit and added the startup workaround I can't remember a single time something went wrong.

While above sounds a bit like hit and miss, I want to point out that I've been using it for 5 months or so and I cannot remeber a single time that it missed a window during normal usage. They were limited to during windows startup, when there's most "stress", explorer opening folder windows while churning away on HD and starting up a bunch of other system stuff at the same time, and my workaround for that since then has worked for me. I've never had it happen when restoring workspaces or manually opening folders.

Perhaps your anti-virus app does some run-time checks when windows get opened, and that additional processing makes the timing/stress issues with SFF happen for you even outside of startup, I don't know.

Having said that, I'm assuming that it actually gets the hook callbacks. Maybe we should still make sure that really is the case for the missed windows. This is pretty easy to test, if close all folders and you run your batch file to open folders and you end up with some wrongly positioned/sized folders, you can check if those folders have been "registered" by SFF or not by going into SFF options and pressing the "Init Defaults From" button. You'll see a popup menu with all registered folders, check if the wrongly sized folders are in that list or not.

 

[kazink]

From what I could see it's not really SFF that has the problem, it's windows. When it calls the hook that a shell window has been created, the internals of the folder window is not completely created yet or not fully registered in explorer or whatever, which seems that in some stress situations could cause issues. I only had those problem in earlier versions though, after changed handling a bit and added the startup workaround I can't remember a single time something went wrong.

Can you make a debug version that logs everything it does (the positions/sizes that it sets) to a text file, and maybe even reads those params back to confirm they are good?

Perhaps your anti-virus app does some run-time checks when windows get opened, and that additional processing makes the timing/stress issues with SFF happen for you even outside of startup, I don't know.

I have uninstalled antivirus, and... it seems to work better. Now more windows of the test group get positioned correctly. The batch file open 9 folders (should be 10, but I must have misspelled one of the names and only 9 open ), and almost always it opened all of them correctly, sometimes 1 or 2 got bad position. Also workspace restoration most often positioned all windows correctly.

Having said that, I'm assuming that it actually gets the hook callbacks. Maybe we should still make sure that really is the case for the missed windows. This is pretty easy to test, if close all folders and you run your batch file to open folders and you end up with some wrongly positioned/sized folders, you can check if those folders have been "registered" by SFF or not by going into SFF options and pressing the "Init Defaults From" button. You'll see a popup menu with all registered folders, check if the wrongly sized folders are in that list or not.

Just tested: all the windows are in the list (checked several times).

I just got an idea, made some tests and I think I found where the problem lies, at least partially: I have dual-core cpu, and if I set SFF to always use one cpu (ProcessExplorer -> Set Affinity), and set Explorer to always use the same cpu, workspace almost always gets restored properly (3 times one of 9 windows got wrong position per 20 workspace restores). When I set SFF to use the other cpu as Explorer - in all tries most (not all) of the windows got positioned wrongly (I have even sometimes saw a glimpse of a window in correct position, and then its full animation ending in wrong position). All it was with uninstalled antivirus. I will install it and retry the test tomorrow maybe (if I have time). It probably can't serve as workaround (I don't know if I can set the affinity to be remembered across program runs), but it may help you find a solution.
However the affinity setting doesn't seem to have any influence on the batch file execution (always most of the windows are good).

One else interesting thing: when I made the batch file to call explorer directly (like "explorer e:\") instead of executing links ("e.lnk"), all the windows always got positioned wrongly.

 

[tweaker]

Can you make a debug version that logs everything it does (the positions/sizes that it sets) to a text file, and maybe even reads those params back to confirm they are good?

Logging to a file would be a little too much work I think, especially since it would have to handle multiple processes where the dll can be injected and stuff. I could maybe enable some debug output that can be viewed/monitored with DbgView (free tool from MS/sysinternals). That's what I use for my own debug builds.

I have uninstalled antivirus, and... it seems to work better. Now more windows of the test group get positioned correctly. The batch file open 9 folders (should be 10, but I must have misspelled one of the names and only 9 open ), and almost always it opened all of them correctly, sometimes 1 or 2 got bad position. Also workspace restoration most often positioned all windows correctly.

...

I just got an idea, made some tests and I think I found where the problem lies, at least partially: I have dual-core cpu, and if I set SFF to always use one cpu (ProcessExplorer -> Set Affinity), and set Explorer to always use the same cpu, workspace almost always gets restored properly (3 times one of 9 windows got wrong position per 20 workspace restores). When I set SFF to use the other cpu as Explorer - in all tries most (not all) of the windows got positioned wrongly (I have even sometimes saw a glimpse of a window in correct position, and then its full animation ending in wrong position).

...

One else interesting thing: when I made the batch file to call explorer directly (like "explorer e:\") instead of executing links ("e.lnk"), all the windows always got positioned wrongly.

All that seems to enforce that it's the timing issue with that the folder window isn't fully created (or initialized) when the hook is called. I'll see if I can make some alternative "safer" method for you to try.

When you do "explorer e:\" you start a new explorer process for each folder, and when an explorer process starts it's definetely a "stress" situation so that makes sense that it goes wrong a lot more there compared to e.lnk.

 

[robertwallace]

ShellFolderFix crashes my Windows Explorer - ouch

First off, let me say that this app is wonderful and greatly eased my shock when I first discovered that Win 7 couldn't remember folder locations, etc. This is an app I'd gladly pay for.

However, this evening I discovered that SFF will crash/hang my Windows Explorer every time when I do the following:

I create a shortcut on the Desktop to a folder on a harddrive (right-click-the-folder -- drag-to-desktop -- create-shortcut-here.) If I right-click on the folder shortcut on the Desktop and select 'Open folder location', the first time, maybe two, it might work and open the containing folder. After that, it will pop up the outline of the folder window and then hang, never filling in the contents.

My options at that point are to kill/restart Explorer, but when it comes back, none of my other disks in 'Computer' will open. They don't hang, they just don't do anything. A reboot clears it up.

I'm running Win7 Home Premium-64 and SFF 1.1.2.0. I don't have the folder option set to 'open each folder in a new process' -- it might help this problem, though it slows things down quite a bit. I'm reluctant to try that while I'm typing this post in case it doesn't work and WinExplorer hangs again.

I've done a cursory search of this posting, though 'open' and 'folder' and 'location', understandably, brings up way too many posts to be able to see if this is a known bug, or if there might be a setting I can toggle to stop this from happening.

Has anyone seen this before? Can someone try it out to see if it's just my situation that's causing this problem for me?

Thanks, Robert

[followup]

If I 'Open file location' from the folder's shortcut properties dialog box instead of the right-click menu, it works normally.
If I have the 'launch folder windows in a separate process' turned on, then even the opening the folder location from the right-click menu works normally.
If I restart Windows Explorer after it hangs and then exit ShellFolderFix, everything's back to normal. If I leave it running, Windows Exlporer remains buggy and mostly unusable.

/[followup]

 

[tweaker]

Does it work if you double-click on the shortcut?

I've never tried opening a shortcut through the right-click menu, will have to try that tomorrow and see if there's any difference.

It does sound like you're experiencing a deadlock issue with SFF. Killing the SFF process when that happens could possibly also resolve the situation, in case you haven't tried that. Not sure why it's happening, from what I remember no one else has reported that kind of problems.

You mentioned that "open each folder in a new process" slows down noticably, so I assume your computer isn't.. how do I put this nicely.. too powerful? Maybe there's some undiscovered issue that happens on less powerful setups. I'll have to see if I can somehow simulate such a situation, unless it turns out that the right-click menu is the source of the problem.