Handling Folder shortcuts
Moderators: fgagnon, nikos, Site Mods
looks like you've got an old version; check out the website for the most recent v1.3.1.10
I have created shortcuts by right clicking on the folder and 'create short cut' then moving that folder to where I want it, I have tried creating the shortcut using the shift+ctrl key combination on the folder whilst dragging it across to where I want it, I have tried the same operations in windows explorer and then trying it 2xExplorer with the same result. This is the same whether it is on a network or local drive.
Could this be a registry setting or a file association problem?
Could this be a registry setting or a file association problem?
Vas
the problem with Vassili was that he had tweaked off the little arrow overlay which appears on shortcut icons. The tweak involved removing the value for "IsShortcut" from registry's HKCR\lnkfile
as a result 2x could not detect the "shortcutness" any more. For him none of the shortcuts worked; it seems that you only have problems with a particular networked one?
as a result 2x could not detect the "shortcutness" any more. For him none of the shortcuts worked; it seems that you only have problems with a particular networked one?
Right, it only seems to happen with a couple of shortcuts that point to network shares.
Here's some detail:
I used your suggestion and built a 'Quick Directory' folder that contains shortcuts to various locations. 90% of the shortcuts are to local directories, but at least three are on network drives.
All of the local directories work as expected; however, at least two of the network shortcuts open up in a separate Explorer window. What's strange is that this doesn't happen 100% of the time; on some occasions those specific shortcuts will work like they should, but unfortunately I've never been able to specifically identify what it was I had done just prior to help figure out what is causing this behavior.
In any case, it's not a big deal but it's definitely puzzling. I'll be sure to follow up if I see any other symptoms/info.
Something else that's been nagging me recently is that it looks like your 'windowclass' changes from one instance to the next which causes some problems with other software I use. Specifically, a virtual window manager I use can make a program 'sticky' based on it's window class. Since 2x's changes, I'm forced to dig into the configuration each time to update the change. This might not be something you can control, but 2x seems to be the only program I use that exhibits this behavior.
Anyway, fantastic program .. I had looked high and low for a file manager that worked just like I wanted it to and yours took the prize. Keep up the great work ..!
Here's some detail:
I used your suggestion and built a 'Quick Directory' folder that contains shortcuts to various locations. 90% of the shortcuts are to local directories, but at least three are on network drives.
All of the local directories work as expected; however, at least two of the network shortcuts open up in a separate Explorer window. What's strange is that this doesn't happen 100% of the time; on some occasions those specific shortcuts will work like they should, but unfortunately I've never been able to specifically identify what it was I had done just prior to help figure out what is causing this behavior.
In any case, it's not a big deal but it's definitely puzzling. I'll be sure to follow up if I see any other symptoms/info.
Something else that's been nagging me recently is that it looks like your 'windowclass' changes from one instance to the next which causes some problems with other software I use. Specifically, a virtual window manager I use can make a program 'sticky' based on it's window class. Since 2x's changes, I'm forced to dig into the configuration each time to update the change. This might not be something you can control, but 2x seems to be the only program I use that exhibits this behavior.
Anyway, fantastic program .. I had looked high and low for a file manager that worked just like I wanted it to and yours took the prize. Keep up the great work ..!
i think the mystery is solved!
2x sets an internal timeout while resolves shortcuts. If this expires then it's "not a shortcut". Now, depending on the network traffic, the speed of the connection etc, it seems that sometimes it makes it and sometimes not. That explains why the failure is intermittent. I'll have to increase the timeout to sort this out
coming to the window class issue, sorry but it is all MFC's fault. I don't register any window classes directly. The only workaround is to find some window manager that locks on to windows judging on the title (and the first few characters at that, since 2x appends the current directory there! )
better luck in the next WTL-based version, where the class name will be constant
Edited By nikos on Mar. 27 2002 at 11:07
2x sets an internal timeout while resolves shortcuts. If this expires then it's "not a shortcut". Now, depending on the network traffic, the speed of the connection etc, it seems that sometimes it makes it and sometimes not. That explains why the failure is intermittent. I'll have to increase the timeout to sort this out
coming to the window class issue, sorry but it is all MFC's fault. I don't register any window classes directly. The only workaround is to find some window manager that locks on to windows judging on the title (and the first few characters at that, since 2x appends the current directory there! )
better luck in the next WTL-based version, where the class name will be constant
Edited By nikos on Mar. 27 2002 at 11:07
> 2x sets an internal timeout while resolves shortcuts.
> If this expires then it's "not a shortcut". Now,
> depending on the network traffic, the speed
> of the connection etc, it seems that sometimes
> it makes it and sometimes not. That explains
> why the failure is intermittent. I'll have to increase
> the timeout to sort this out
That's interesting; hopefully it will resolve the issue.
One thing I did notice was that it seems to happen 'more' consistently when the shortcut points to a directory deeper in the directory tree on the share. (ie. \\computer\share\blah\blah\blah) Another shortcut pointing to the root of that same share not only seems to work more often, but if I use that shortcut first and then use the other shortcut (that points to the same share, but deeper) then that one works as well.
> coming to the window class issue, sorry but it
> is all MFC's fault. I don't register any window
> classes directly. The only workaround is to
> find some window manager that locks on to
> windows judging on the title (and the first
> few characters at that, since 2x appends
> the current directory there! )
> better luck in the next WTL-based version,
> where the class name will be constant
Sounds great. I'm able to use the partial window title trick in another program I use but unfortunately the VWM isn't as flexible. However, I consider that a shortcoming on their part, not yours. *grin*
Thanks again for all of your help.
> If this expires then it's "not a shortcut". Now,
> depending on the network traffic, the speed
> of the connection etc, it seems that sometimes
> it makes it and sometimes not. That explains
> why the failure is intermittent. I'll have to increase
> the timeout to sort this out
That's interesting; hopefully it will resolve the issue.
One thing I did notice was that it seems to happen 'more' consistently when the shortcut points to a directory deeper in the directory tree on the share. (ie. \\computer\share\blah\blah\blah) Another shortcut pointing to the root of that same share not only seems to work more often, but if I use that shortcut first and then use the other shortcut (that points to the same share, but deeper) then that one works as well.
> coming to the window class issue, sorry but it
> is all MFC's fault. I don't register any window
> classes directly. The only workaround is to
> find some window manager that locks on to
> windows judging on the title (and the first
> few characters at that, since 2x appends
> the current directory there! )
> better luck in the next WTL-based version,
> where the class name will be constant
Sounds great. I'm able to use the partial window title trick in another program I use but unfortunately the VWM isn't as flexible. However, I consider that a shortcoming on their part, not yours. *grin*
Thanks again for all of your help.