App to Control Explorer Right-Click Menu?

  • Thread starter Thread starter frank
  • Start date Start date
F

frank

Hi,

I'd like to remove some of the items on the Explorer right-click menu,
particularly the "New" options. Can anyone recommend such an app for XP
Home?

Thanks,
 
frank ([email protected]) schrieb/wrote:
I'd like to remove some of the items on the Explorer right-click menu,
particularly the "New" options. Can anyone recommend such an app for
XP Home?

In W9x, the templates for the files listed under "New"
are located in C:\Windows\ShellNew.
 
frank said:
Hi,

I'd like to remove some of the items on the Explorer right-click menu,
particularly the "New" options. Can anyone recommend such an app for
XP Home?

Thanks,

Tweak UI (go to 'Templates'). Total control...add/delete at
will...And...while you're in the program, look at all the other great things
you can do!

Regards...
 
Won Dampchin said:
Tweak UI (go to 'Templates'). Total control...add/delete at
will...And...while you're in the program, look at all the other great things
you can do!

Tweak UI is the traditional way, and I cannot imagine a Win install without
it. Also to mention, cleaning that menu is something you should expect from
other "reg tweakers" too.

If you want to access the registry directly, either with a registry editor,
else with a registry SR utility: the key you search for is named ShellNew,
as a subkey under an extension key type.

For example:

HKCR\.txt
HKCR\.txt\ShellNew "NullFile"=""

Or the variation, which launches a template file (area for customize, btw):

HKCR\.bat\ShellNew "FileName"="run.bat"

As to clean up, however you do it, TweakUI or otherwise, it won't solve a
major problem. A number of apps are programmed to auto-add a ShellNew key,
every time you run them. This is infuriating.

Worse, it's a crime committed even by some of my favorite programs (eg
PowerArch, Winhttrack). So what can you do about that? Clean up after the
program every time you run it? That's what I do for my infrequently-used
programs that inflict various undesirable registry adds. But cases like
the two examples I gave, I run those all the time, so I am fairly helpless
about their relentless contamination of my explorer New menu.

Does XP home, or do any of the post-9x OS, offer registry protection from
software that does this?

(By setting permissions on reg keys? By doing an override in subkeys under
HKCU\Software\Classes\? By resorting to Policy setting to do with freezing
associations?)

My experience is largely limited to 9x, so I cannot answer easily, but
have definitely wondered.
 
omega said:
"Won Dampchin" <[email protected]>:
If you want to access the registry directly, either with a registry editor,
else with a registry SR utility: the key you search for is named ShellNew,
as a subkey under an extension key type.

For example:

HKCR\.txt
HKCR\.txt\ShellNew "NullFile"=""

Or the variation, which launches a template file (area for customize, btw):

HKCR\.bat\ShellNew "FileName"="run.bat"

As to clean up, however you do it, TweakUI or otherwise, it won't solve a
major problem. A number of apps are programmed to auto-add a ShellNew key,
every time you run them. This is infuriating.

Worse, it's a crime committed even by some of my favorite programs (eg
PowerArch, Winhttrack). So what can you do about that? Clean up after the
program every time you run it? That's what I do for my infrequently-used
programs that inflict various undesirable registry adds. But cases like
the two examples I gave, I run those all the time, so I am fairly helpless
about their relentless contamination of my explorer New menu.

Does XP home, or do any of the post-9x OS, offer registry protection from
software that does this?
(By setting permissions on reg keys? By doing an override in subkeys under
HKCU\Software\Classes\? By resorting to Policy setting to do with freezing
associations?)

Win NT/2K/XP does have security attributes for registry entries. You
can't see them or change them from regedit, but you can from regedt32.
I haven't tried it, but you should be able to set the security of the
HKCR/.txt/ShellNew key to make it unwritable, which would prevent the
program from changing it.

Another option would be to create a registry script (.reg) file that
clears these entries, then run this after you run the offending
programs. You still have to remember to run the script, but at least
it's easier than running regedit and manually deleting the key.

I would have tried this for you just to see if it worked, but as far
as I know I don't have a program installed that exhibits this annoying
behavior.

Terry
 
Terry Orchard said:
Win NT/2K/XP does have security attributes for registry entries. You
can't see them or change them from regedit, but you can from regedt32.
I haven't tried it, but you should be able to set the security of the
HKCR/.txt/ShellNew key to make it unwritable, which would prevent the
program from changing it.

Yes, that sounds ideal. If the permission on HKCR\.txt\ShellNew, then
would have to experiment for a value type that would not show up in explorer
menu. Or if on HKCR\.txt, would that prevent creation of ShellNew subkey?
Bonus for HKCR\.txt, could prevent the standard means of association hijacks,
by not letting the filetype value entry there get changed.
I would have tried this for you just to see if it worked, but as far
as I know I don't have a program installed that exhibits this annoying
behavior.

A couple more to the list. InfoRapid Search and Replace. And, the resource
kit tool, FileImg... Hm, scratch that secod one, it's a reskit tool that's
only officially 9X and NT4. Please allow me time to look out for a fuller
list. As I'd be most interested in having you do a test.
Another option would be to create a registry script (.reg) file that
clears these entries, then run this after you run the offending
programs. You still have to remember to run the script, but at least
it's easier than running regedit and manually deleting the key.

Yes, I run a number of programs to clean up after themselves (start /w).
But, prog like PowerArch, it is not feasible. I generally launch it by its
shell extension DLL. On drag-drop action of an archive. And do so quite
often. So it recreates the shellnew entry 100 times more frequently than
I can delete it. (And I'm not up to configuring and keeping resident
something in the background that watches for its windows; actually I
can't even see that line of strategy do-able in the Powerarch type case.)

PowerArch, it additionally does some other registry debris at HKCR which
bothers me. I contemplate that for this one, I might be best off letting
go and looking for a replacement for it. A zip util that has the same
features that I most value, without the forced reg debris.

Or, at the point where I run 2000, perhaps it will be that I can have more
control over the registry (in presets/locks) against some of the standard
offenses inflicted by programs. As in, the question here, the automatic
ShellNew key creations.
 
omega said:
Yes, that sounds ideal. If the permission on HKCR\.txt\ShellNew, then
would have to experiment for a value type that would not show up in explorer
menu. Or if on HKCR\.txt, would that prevent creation of ShellNew subkey?

There is a "create subkey" permission. Along with Query Value, Set
Value, and various others.

Terry
 
Win NT/2K/XP does have security attributes for registry entries. You
can't see them or change them from regedit, but you can from regedt32.
I haven't tried it, but you should be able to set the security of the
HKCR/.txt/ShellNew key to make it unwritable, which would prevent the
program from changing it.

I would have tried this for you just to see if it worked, but as far
as I know I don't have a program installed that exhibits this annoying
behavior.

Some programs which auto-insert a shellnew subkey...

website downloader: Webreaper (.reap)
website downloader: WinHttrack (.whtt)
bookmark manager/dbs: Gul (.gul)
html/notes/urls dbs: Webnotes (.ws)
editor/dbs: Correlate Knowledge Map (.kmp)
zip util: PowerArchiver (.zip)
SR util: InfoRapid Search & Replace (.se)
directory snapshot and compare: FileImg (.fii, .fid)
reg editor (a terminal beta): Vilma Registry Explorer (.rxp)
reg cleaner: Regmaid (.rmd)
proc logging: Api Monitor (.apm)

Yes, these also forcibly create their vanity filetype + extension keys,
along with the shellnew subkey. I dislike that in itself, forced filetype
entries. But it's the shellnew that makes for the most immediate annoyance.
Since it shows up immediately in one's working interface.

Terry, would you be willing to test the Reged32 permissions against one of
those programs? I'd suggest Winhttrack, no-install, or better, Api Monitor.
Some in that list add other things, CLSID type stuff, on run. But both of
these, it's the three keys alone: their filetype keys, and their HKCU entry.

WinHttrack creates these keys:
HKCR\.whtt
HKCR\WinHTTrackProject
HKCU\Software\WinHTTrack Website Copier

API Monitor creates these keys:
HKCR\.apm
HKCR\APIMonitor.Document
HKCU\Software\Rohitab Batra

http://www.rohitab.com/apimonitor/
http://www.rohitab.com/apimonitor/apimonitor.zip (340k)
 
omega said:
Terry, would you be willing to test the Reged32 permissions against one of
those programs? I'd suggest Winhttrack, no-install, or better, Api Monitor.
Some in that list add other things, CLSID type stuff, on run. But both of
these, it's the three keys alone: their filetype keys, and their HKCU entry.

I tested winhttrack. It works as expected. In HKCR/.whht I set "create
subkey" to deny permission. Then ran winhttrack. No subkey gets
created, and the shell new menu does not show the "new winhttrack
project" entry.

BTW, I didn't try API Monitor because it appears to not run under XP.
It lists Windows 95/98/NT/2000/ME/2003 as system requirements. Weird.

Terry
 
Terry Orchard said:
I tested winhttrack. It works as expected. In HKCR/.whht I set "create
subkey" to deny permission. Then ran winhttrack. No subkey gets
created, and the shell new menu does not show the "new winhttrack
project" entry.

Thank you for the testing.

Good news that the annoyance can be prevented. When I run 2000, I'll
look forward to the options with permissions.
BTW, I didn't try API Monitor because it appears to not run under XP.
It lists Windows 95/98/NT/2000/ME/2003 as system requirements. Weird.

When I looked on the page for OS compatibility, I didn't even catch
that weird omission. That particular sequence, it has got to be unique...
 
Back
Top