Just loaded up the shellfolderfix program, and what a relief.
The various problems introduced with WIn7 Explorer are enough to make upgrading painful.
Your program is a great start in smoothing out the transition.
Thanks so much.
Keep up the great work!
pauljayd
P.S. (Of course...)
Might it be possible to get the navigation panel to move the in-focus right-panel object close to the top?
Sorry, it's just my frustration with the new Win7 Explorer - Every time I play with it (I toggle back and forth with my 'production' WinXP) all the little quirks just jump right back in my face.
So, I start Windows Explorer, and have the Organize/Layout/Navigation pane activated. I then begin to drill down to a sub-folder. In the Navigation pane I click 'Computer' then 'ToshWin7C (C:)', which is my c-drive.
It's highlighted in the left pane, but stays near the bottom of it. Of course it also opens in the right pane. Continuing, I wish to click "Windows", but must first scroll the left pane down. In WinXP, when you click an item in the left pane, it would cause the left pane to scroll automatically, bringing the highlighted item towards the top of the pane, exposing much of its contents. So, I scroll the left pane, and click "Windows".
The "Windows" item highlights, opens in the the right pane, but stays near the bottom of the left pane -- not showing much of it's contents (in the left). I must repeatedly scroll the left pane to keep the highlighted item near the top.
It's just tiresome.
It seems to me that if the user has just clicked an item in the left pane to expand it, it should move towards the top of the screen, as normal viewing is top-to-bottom, left-to-right. It just doesn't feel/look right to me, whereas XP did.
Thanks.
Tweaker,
I came across ShellFolderFix today and it works great. I wasn't needing anything more than to have windows remember folder sizes and positions on the screen. I don't understand why this was taken away. I have the 64-bit windows 7 and it work with no problem. When I exit the program windows immediately screws up any customization I just accomplished, and it is nice to see that when I start the program up again everything falls right back into place. I am just testing it right now but most likely I will have it start at boot and always running. Great work and thanks!
Ah I see. That's lower level functionality of how that list/tree control works, that's currently a little outside of what the app does. That might change at a later point depending on other things added.
You could ask Ivo that does Classic Shell and see if that is something he thinks is possible in that project. I think the type of program that is (explorer extension) would be in a better position for such a fix.
Too bad it wasn't that, but at least it helps in that I can eliminate that part of the code as the problem.
It sounds like some kind of timing problem, meaning that for a very brief moment the window name is something else until the internal data is created and the correct path is available. What could affect that if it's a slower computer and/or if the shortcut points to a network folder or removable media. You mentioned that it usually happens the first time, then it works again directly after, this also fits the description as after the first time the data is cached in memory (at least for a while).
Do your shortcuts point to folders on your local harddisk or something else?
It happens not only first time but after long time of inactivity or another work too.
I do not have a network maps or another slow drives on this machine. And machine is powerfull enought (quadcore CPU, 4GB RAM, Windows7 64bit).
May be a problem is connected to "green power" HDDs which have internal aggressive power management (I can't disable this)? But I don't hear an HDD's startup when I see a problem with folder's size...
Noticed a bit of a bug (or odd behavior).
When using the option of "Temporarily use window as is", when you have a bunch of windows you opened from the same starting path and you try to save the workspace, it doesn't save all of the windows (couldn't figure out exactly why it was choosing certain ones though).
You mean if you have any windows open where you navigated to a new location inside that window (basically when the explorer back button is enabled). Yes those are not saved in workspaces, as those windows are... well... temporary :)
This was intentional, or rather necessary by design because of what workspace data consists of. What would be possible without "hacks", would be that those temporary folders are saved in a workspace, but when the workspace is restored those folders will be opened with the folders' "real" window size/position and not the temporary one. Would that work for you?
Basically what I have is this:
shortcut on desktop to a/
I open a/ and move to a/b/c/
I open a/ and move to a/b/c/d/
I open a/ and move to a/b/c/e/
etc
I do that 9 times to open up all of the windows I need and move them to the proper place (with a nice tool called gridmove) and then save the workstation. I spent a few minutes trying to figure out why they were not being saved until I changed that setting. I would think that most who try doing the same thing (with any setting really) would expect it to save and open all the directories as they were and probably would be confused as I was to why it wasn't saving them.
Quote