ShellFolderFix - Manage folder window positions/size

Page 20 of 60 FirstFirst ... 10181920212230 ... LastLast

  1. Posts : 20
    Windows 7 - 64, Windows XP
       #191

    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?
      My Computer


  2. Posts : 194
    w7-64, w2k
    Thread Starter
       #192

    kazink said:
    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.

    kazink said:
    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.

    kazink said:
    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.

    kazink said:
    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.)
      My Computer


  3. Posts : 20
    Windows 7 - 64, Windows XP
       #193

    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.
      My Computer


  4. Posts : 194
    w7-64, w2k
    Thread Starter
       #194

    kazink said:
    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.
      My Computer


  5. Posts : 20
    Windows 7 - 64, Windows XP
       #195

    tweaker said:
    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.
      My Computer


  6. Posts : 194
    w7-64, w2k
    Thread Starter
       #196

    kazink said:
    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.
      My Computer


  7. Posts : 20
    Windows 7 - 64, Windows XP
       #197

    tweaker said:
    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?

    tweaker said:
    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.

    tweaker said:
    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.
      My Computer


  8. Posts : 194
    w7-64, w2k
    Thread Starter
       #198

    kazink said:
    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.
      My Computer


  9. Posts : 6
    Windows 7 Home Premium
       #199

    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]
    Last edited by robertwallace; 12 May 2010 at 22:27. Reason: additional info
      My Computer


  10. Posts : 194
    w7-64, w2k
    Thread Starter
       #200

    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.
      My Computer


 
Page 20 of 60 FirstFirst ... 10181920212230 ... LastLast

  Related Discussions
Our Sites
Site Links
About Us
Windows 7 Forums is an independent web site and has not been authorized, sponsored, or otherwise approved by Microsoft Corporation. "Windows 7" and related materials are trademarks of Microsoft Corp.

© Designer Media Ltd
All times are GMT -5. The time now is 23:43.
Find Us