Problem - Win7 64bit Context [Send to]

NTFS permissions look fine - bummer.

How about file attributes?

A shortcut with the Hidden attribute should not show in the Send to context menu.

This is what a normal (not hidden) shortcut looks like:


Can you please post that info for the EditPad Pro.lnk?

Code:

attrib "C:\Users\Edward\AppData\Roaming\Microsoft\Windows\SendTo\EditPad Pro.lnk"

UsernameIssues said:

How about file attributes?

A shortcut with the Hidden attribute should not show in the Send to context menu.

A stab in the dark suggestion; the Shortcuts seen in the image don't look as if they have the Hidden attribute, UsernameIssues.


Tecknomage, could you follow my post #24 and report back your findings?

Pyprohly said:

UsernameIssues said:

How about file attributes?

A shortcut with the Hidden attribute should not show in the Send to context menu.

A stab in the dark suggestion; the Shortcuts seen in the image don't look as if they have the Hidden attribute, UsernameIssues.


Tecknomage, could you follow my post #24 and report back your findings?

I agree. They do not look dim/hidden to me either. I checked that before posting. However, I'm old and the contrast on this laptop screen is not all that great. I figured it best to ask what attrib showed instead of going by what I think I see. I also wondered if the icon dimming scheme might be messed up - since something is weird about that folder.


About your test in post #24.
Here is something for you to try...
...navigate via Windows Explorer to your Send to folder
...rename that Documents shortcut
(Maybe Documents7777)
...keep the Windows Explorer window in view
...stare at that renamed Documents shortcut......
......while you right click on most any other file or folder.

You can also bring Windows Explorer back into focus (if need be) and press Ctrl-Z.

Your test is much simpler/quicker.
My version of that test is fun


Tecknomage's original post mentioned using SHELL:SENDTO to open the applicable folder. This was mentioned again in post #23 and #26. I'm not sure if that test is about the same as your test in post #24. Your test (and its results) are sure simpler to wrap my feeble mind around - since I'm not clear if Explorer consults SHELL:SENDTO before building these context menus. Process Monitor showed that a ton of stuff happens to create these context menus, but I never found SHELL:SENDTO in the mix. Of course, Process Monitor confirms exactly which folder is used to build the context menu (and its sub-menus).


tecknomage,
Do you still have the test account that you mentioned in post #26? If so, can you please post a screenshot from that account just like the excellent screenshot that you attached to post #17?

Also, I know that post #6 is from last year and lots of stuff could have changed since then, but could you also provide us with a screenshot of the Send to folder from the Default profile folder? As I understand things, that Default profile is copied to each new user profile... but I could be wrong.

SHELL:SENDTO command opens the same folder that has the problem. And yes, creating another Account did NOT solve the problem, that new Account's SendTo folder also did not display any shortcut I put into it.

tecknomage said:

SHELL:SENDTO command opens the same folder that has the problem. And yes, creating another Account did NOT solve the problem, that new Account's SendTo folder also did not display any shortcut I put into it.

I already knew that a new account did not solve the problem.

You only seem to be responding to the last post in your thread each time that you visit. I'll leave you in the capable hands of Pyprohly.