Registry tweak?

[P. H. Allen]

Is there a registry tweak to keep various applications from inserting an
added line in the context menu under "New?" I am only wanting to see
"Folder" and "Shortcut" listed when I use this feature. To date I have been
using TweakUI, however that process gets old fast, and it would be nice to
avoid having to do anything except the initial registry modification.
Thanks.

 

[Unk]

Is there a registry tweak to keep various applications from inserting an
added line in the context menu under "New?" I am only wanting to see
"Folder" and "Shortcut" listed when I use this feature. To date I have been
using TweakUI, however that process gets old fast, and it would be nice to
avoid having to do anything except the initial registry modification.
Thanks.

Microsoft TweakUI
http://www.microsoft.com/windowsxp/pro/downloads/powertoys.asp
http://download.microsoft.com/download/whistler/Install/2/WXP/EN-US/TweakUiPowertoySetup.exe

Click "Templates" and uncheck everything you don't want. Apply, OK

 

[P. H. Allen]

Did you even read my original post? If so, your retention skills are very
poor.

 

[Jon]

You only have yourself to blame for a poor thread and spending yet another
day pondering such a simple question. You made the decision to ignore my
comments in your last thread, make no reply, offensively open up a
completely new thread, and then respond abusively to someone else who tried
to help.

A simple script that deleted these registry keys would solve your problem,
but it won't be me who taps it out, since I'm off to watch Brazil v Croatia.

HKEY_LOCAL_MACHINE\SOFTWARE\Classes\.<particular extension here>\ShellNew
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\Discardable\PostSetup\ShellNew\<relevant
entry>

--
Jon

If it's there and you can see it - it's real. If it's not there and you can
see it - it's virtual. If it's there and you can't see it - it's
transparent. If it's not there and you can't see it - you erased it!

 

[P. H. Allen]

Everyone seems to want to tell me what I have either already done or already
know, Jon.

Your recent suggestion of erasing those keys will result in having to
re-install some, (e. g. MS Streets and Trips) but not all programs which I
am seeking
to keep from adding their signature to the context menu. I am not interested
in solving the problem in that fashion. I think that the suggestion to
delete the keys is somewhat similar to telling me to cut off my leg to cure
an infection. So if you were tapping the script out in lieu of watching the
game, I would not be interested. Not only that, but anyone using TweakUI has
the capability of deleting the keys within that utility. With that
available, who would need such a script?

In your initial response to the post regarding this problem, the suggestion
of adjusting the permissions did, I though, have merit. However I was not
able to get it to respond favorably, and reposted simply because I am aware
of the huge number of posts on this newsgroup and knew that in a few hours,
my post would be at the bottom of the heap, and thus ignored.

You apparently viewed my response to that other person as abusive, but when
I have already written **clearly** that I have been using TweakUI to handle
the problem and someone suggests TweakUI as a solution, well, you tell me
what you would call it. I am sticking with my position on that matter.

Those keys can be controlled with an entry which will determine true(1) or
false(0) and I needed to know how to implement the modification. It seems
that no one seems to have that knowledge at this newsgroup, or they are
remaining
silent.

 

[Jon]

........ I have been using TweakUI to handle

the problem ..............

.......Those keys can be controlled with an entry which will determine
true(1) or
false(0) and I needed to know how to implement the modification. It seems
that no one seems to have that knowledge at this newsgroup, or they are
remaining
silent.

Ok, I can see now how you may have gained the impression from TweakUI that
there is a simple on /off switch for 'New menu' entries.

What TweakUI does, when toggling the New menu entry between enabled and
disabled, is to rename the aforementioned 'ShellNew' key, *for a particular
extension* to 'ShellNew-', (ie it puts a hyphen on the end of it). - thus
rendering the registry entry , *for that particular extension only* invalid.

eg for an extension, say xyz,

HKEY_LOCAL_MACHINE\SOFTWARE\Classes\.xyz\ShellNew
[or what is the same
HKEY_CLASSES_ROOT\.xyz\ShellNew ]
it is renamed to
HKEY_LOCAL_MACHINE\SOFTWARE\Classes\.xyz\ShellNew-

To delete the entry it removes the ShellNew key entirely.

When you run TweakUI, as well as noting 'ShellNew' keys, it also highlights
the 'ShellNew-' keys, and presents them to you as disabled forms of the
previous.

However, it would be a simple matter for a program to readd a legitimate
'ShellNew' key, which is what you are observing.


Jon

 

[P. H. Allen]

For **every** other Microsoft program (e. g. Word, Excel, PowerPoint, etc.,
and others like Adobe Reader, when clicking on the document template in
TweakUI to remove the checkmark, the utility renames the Shellnew key to
Shellnew-. This ends the process of adding the application to the context
menu under "New." However for MS Streets and Trips, TweakUI actually deletes
the key. If I manually rename the key to Shellnew- in the registry, MS
streets and Trips adds a new Shellnew key adjacent to the renamed Shellnew-
key as you have stated below.

I was hoping to find a way to keep the MS S&T application from adding a new
key each time it opens. That hope is becoming the impossible dream. I guess
it is time to say, "uncle."

....... I have been using TweakUI to handle

the problem ..............

.......Those keys can be controlled with an entry which will determine
true(1) or
false(0) and I needed to know how to implement the modification. It seems
that no one seems to have that knowledge at this newsgroup, or they are
remaining
silent.

Ok, I can see now how you may have gained the impression from TweakUI that
there is a simple on /off switch for 'New menu' entries.

What TweakUI does, when toggling the New menu entry between enabled and
disabled, is to rename the aforementioned 'ShellNew' key, *for a
particular extension* to 'ShellNew-', (ie it puts a hyphen on the end of
it). - thus rendering the registry entry , *for that particular extension
only* invalid.

eg for an extension, say xyz,

HKEY_LOCAL_MACHINE\SOFTWARE\Classes\.xyz\ShellNew
[or what is the same
HKEY_CLASSES_ROOT\.xyz\ShellNew ]
it is renamed to
HKEY_LOCAL_MACHINE\SOFTWARE\Classes\.xyz\ShellNew-

To delete the entry it removes the ShellNew key entirely.

When you run TweakUI, as well as noting 'ShellNew' keys, it also
highlights the 'ShellNew-' keys, and presents them to you as disabled
forms of the previous.

However, it would be a simple matter for a program to readd a legitimate
'ShellNew' key, which is what you are observing.


Jon

 

[Jon]

An alternative approach would be to try and fool MS S&T into thinking the
key already exists and hence that there is no need to try and re-add it. The
success of this would depend on how thoroughly it checks that the ShellNew
key has been correctly added.

So, for example you could delete just the subvalue of ShellNew, which might
be 'NullFile', (or 'config', 'filename', 'command', 'data' ). After opening
the New menu a couple of times, the entry should have disappeared. That
*may* be sufficient to fool the program into thinking that the key already
exists and hence that there is no need to re-add it, when the program is
run. I don't use the program myself, so I can't test it.

Other possibilities might include (assuming an 'xyz' extension for MS S&T
and that the value of the "(default)" key at
HKEY_LOCAL_MACHINE\SOFTWARE\Classes\.xyz is 'xyzdefaultvalue' )


(1) Open up the text for the '(default)' key at
HKEY_LOCAL_MACHINE\SOFTWARE\Classes\xyzdefaultvalue
and remove the text (ie double-click it, remove the text and close it)

[NB Don't remove the text for the '(default)' value at
HKEY_LOCAL_MACHINE\SOFTWARE\Classes\xyz ]

OR

(2) Delete this key if it exists and also do step (1)
HKEY_LOCAL_MACHINE\SOFTWARE\Classes\xyzdefaultvalue\FriendlyTypeName

[NB Make suitable exports of the above registry keys, if you wish to restore
them to their original condition later. ]


Jon

For **every** other Microsoft program (e. g. Word, Excel, PowerPoint,
etc., and others like Adobe Reader, when clicking on the document template
in TweakUI to remove the checkmark, the utility renames the Shellnew key
to Shellnew-. This ends the process of adding the application to the
context menu under "New." However for MS Streets and Trips, TweakUI
actually deletes the key. If I manually rename the key to Shellnew- in the
registry, MS streets and Trips adds a new Shellnew key adjacent to the
renamed Shellnew- key as you have stated below.

I was hoping to find a way to keep the MS S&T application from adding a
new key each time it opens. That hope is becoming the impossible dream. I
guess it is time to say, "uncle."

....... I have been using TweakUI to handle

the problem ..............

.......Those keys can be controlled with an entry which will determine
true(1) or
false(0) and I needed to know how to implement the modification. It
seems
that no one seems to have that knowledge at this newsgroup, or they are
remaining
silent.

Ok, I can see now how you may have gained the impression from TweakUI
that there is a simple on /off switch for 'New menu' entries.

What TweakUI does, when toggling the New menu entry between enabled and
disabled, is to rename the aforementioned 'ShellNew' key, *for a
particular extension* to 'ShellNew-', (ie it puts a hyphen on the end of
it). - thus rendering the registry entry , *for that particular extension
only* invalid.

eg for an extension, say xyz,

HKEY_LOCAL_MACHINE\SOFTWARE\Classes\.xyz\ShellNew
[or what is the same
HKEY_CLASSES_ROOT\.xyz\ShellNew ]
it is renamed to
HKEY_LOCAL_MACHINE\SOFTWARE\Classes\.xyz\ShellNew-

To delete the entry it removes the ShellNew key entirely.

When you run TweakUI, as well as noting 'ShellNew' keys, it also
highlights the 'ShellNew-' keys, and presents them to you as disabled
forms of the previous.

However, it would be a simple matter for a program to readd a legitimate
'ShellNew' key, which is what you are observing.


Jon

 

[Uncle Grumpy]

Is there a registry tweak to keep various applications from inserting an
added line in the context menu under "New?" I am only wanting to see
"Folder" and "Shortcut" listed when I use this feature. To date I have been
using TweakUI, however that process gets old fast, and it would be nice to
avoid having to do anything except the initial registry modification.

There are four rules that govern all of this:

RULE 1: Shit happens
RULE 2: Sometimes it happens to you
RULE 3: Sometimes you can't change the shit that happens to you
RULE 4: Learn to live with it and move on

 

[P. H. Allen]

Jon, I have been camping since Wednesday and just returned home. I will give
your suggestions a try, and get back to you with the results.

An alternative approach would be to try and fool MS S&T into thinking the
key already exists and hence that there is no need to try and re-add it.
The success of this would depend on how thoroughly it checks that the
ShellNew key has been correctly added.

So, for example you could delete just the subvalue of ShellNew, which
might be 'NullFile', (or 'config', 'filename', 'command', 'data' ). After
opening the New menu a couple of times, the entry should have disappeared.
That *may* be sufficient to fool the program into thinking that the key
already exists and hence that there is no need to re-add it, when the
program is run. I don't use the program myself, so I can't test it.

Other possibilities might include (assuming an 'xyz' extension for MS S&T
and that the value of the "(default)" key at
HKEY_LOCAL_MACHINE\SOFTWARE\Classes\.xyz is 'xyzdefaultvalue' )


(1) Open up the text for the '(default)' key at
HKEY_LOCAL_MACHINE\SOFTWARE\Classes\xyzdefaultvalue
and remove the text (ie double-click it, remove the text and close it)

[NB Don't remove the text for the '(default)' value at
HKEY_LOCAL_MACHINE\SOFTWARE\Classes\xyz ]

OR

(2) Delete this key if it exists and also do step (1)
HKEY_LOCAL_MACHINE\SOFTWARE\Classes\xyzdefaultvalue\FriendlyTypeName

[NB Make suitable exports of the above registry keys, if you wish to
restore them to their original condition later. ]


Jon

For **every** other Microsoft program (e. g. Word, Excel, PowerPoint,
etc., and others like Adobe Reader, when clicking on the document
template in TweakUI to remove the checkmark, the utility renames the
Shellnew key to Shellnew-. This ends the process of adding the
application to the context menu under "New." However for MS Streets and
Trips, TweakUI actually deletes the key. If I manually rename the key to
Shellnew- in the registry, MS streets and Trips adds a new Shellnew key
adjacent to the renamed Shellnew- key as you have stated below.

I was hoping to find a way to keep the MS S&T application from adding a
new key each time it opens. That hope is becoming the impossible dream. I
guess it is time to say, "uncle."

....... I have been using TweakUI to handle
the problem ..............

.......Those keys can be controlled with an entry which will determine
true(1) or
false(0) and I needed to know how to implement the modification. It
seems
that no one seems to have that knowledge at this newsgroup, or they are
remaining
silent.


Ok, I can see now how you may have gained the impression from TweakUI
that there is a simple on /off switch for 'New menu' entries.

What TweakUI does, when toggling the New menu entry between enabled and
disabled, is to rename the aforementioned 'ShellNew' key, *for a
particular extension* to 'ShellNew-', (ie it puts a hyphen on the end of
it). - thus rendering the registry entry , *for that particular
extension only* invalid.

eg for an extension, say xyz,

HKEY_LOCAL_MACHINE\SOFTWARE\Classes\.xyz\ShellNew
[or what is the same
HKEY_CLASSES_ROOT\.xyz\ShellNew ]
it is renamed to
HKEY_LOCAL_MACHINE\SOFTWARE\Classes\.xyz\ShellNew-

To delete the entry it removes the ShellNew key entirely.

When you run TweakUI, as well as noting 'ShellNew' keys, it also
highlights the 'ShellNew-' keys, and presents them to you as disabled
forms of the previous.

However, it would be a simple matter for a program to readd a legitimate
'ShellNew' key, which is what you are observing.


Jon

 

[Jon]

No problem - I've got the thread bookmarked.

--
Jon

Where is the wisdom we have lost in knowledge?
Where is the knowledge we have lost in information?

- T.S. Elliot

Jon, I have been camping since Wednesday and just returned home. I will
give your suggestions a try, and get back to you with the results.

An alternative approach would be to try and fool MS S&T into thinking the
key already exists and hence that there is no need to try and re-add it.
The success of this would depend on how thoroughly it checks that the
ShellNew key has been correctly added.

So, for example you could delete just the subvalue of ShellNew, which
might be 'NullFile', (or 'config', 'filename', 'command', 'data' ).
After opening the New menu a couple of times, the entry should have
disappeared. That *may* be sufficient to fool the program into thinking
that the key already exists and hence that there is no need to re-add it,
when the program is run. I don't use the program myself, so I can't test
it.

Other possibilities might include (assuming an 'xyz' extension for MS S&T
and that the value of the "(default)" key at
HKEY_LOCAL_MACHINE\SOFTWARE\Classes\.xyz is 'xyzdefaultvalue' )


(1) Open up the text for the '(default)' key at
HKEY_LOCAL_MACHINE\SOFTWARE\Classes\xyzdefaultvalue
and remove the text (ie double-click it, remove the text and close it)

[NB Don't remove the text for the '(default)' value at
HKEY_LOCAL_MACHINE\SOFTWARE\Classes\xyz ]

OR

(2) Delete this key if it exists and also do step (1)
HKEY_LOCAL_MACHINE\SOFTWARE\Classes\xyzdefaultvalue\FriendlyTypeName

[NB Make suitable exports of the above registry keys, if you wish to
restore them to their original condition later. ]


Jon

For **every** other Microsoft program (e. g. Word, Excel, PowerPoint,
etc., and others like Adobe Reader, when clicking on the document
template in TweakUI to remove the checkmark, the utility renames the
Shellnew key to Shellnew-. This ends the process of adding the
application to the context menu under "New." However for MS Streets and
Trips, TweakUI actually deletes the key. If I manually rename the key to
Shellnew- in the registry, MS streets and Trips adds a new Shellnew key
adjacent to the renamed Shellnew- key as you have stated below.

I was hoping to find a way to keep the MS S&T application from adding a
new key each time it opens. That hope is becoming the impossible dream.
I guess it is time to say, "uncle."




....... I have been using TweakUI to handle
the problem ..............

.......Those keys can be controlled with an entry which will determine
true(1) or
false(0) and I needed to know how to implement the modification. It
seems
that no one seems to have that knowledge at this newsgroup, or they
are remaining
silent.


Ok, I can see now how you may have gained the impression from TweakUI
that there is a simple on /off switch for 'New menu' entries.

What TweakUI does, when toggling the New menu entry between enabled and
disabled, is to rename the aforementioned 'ShellNew' key, *for a
particular extension* to 'ShellNew-', (ie it puts a hyphen on the end
of it). - thus rendering the registry entry , *for that particular
extension only* invalid.

eg for an extension, say xyz,

HKEY_LOCAL_MACHINE\SOFTWARE\Classes\.xyz\ShellNew
[or what is the same
HKEY_CLASSES_ROOT\.xyz\ShellNew ]
it is renamed to
HKEY_LOCAL_MACHINE\SOFTWARE\Classes\.xyz\ShellNew-

To delete the entry it removes the ShellNew key entirely.

When you run TweakUI, as well as noting 'ShellNew' keys, it also
highlights the 'ShellNew-' keys, and presents them to you as disabled
forms of the previous.

However, it would be a simple matter for a program to readd a
legitimate 'ShellNew' key, which is what you are observing.


Jon

 

[P. H. Allen]

I have had no luck "fooling" the MS S&T. Any alterations provokes the
program to re-write the registry key. I feel certain that there is a method
to achieve what I am needing, but I am at a loss as to what it would be.
Thanks for all of your help and suggestions.

No problem - I've got the thread bookmarked.

--
Jon

Where is the wisdom we have lost in knowledge?
Where is the knowledge we have lost in information?

- T.S. Elliot

Jon, I have been camping since Wednesday and just returned home. I will
give your suggestions a try, and get back to you with the results.

An alternative approach would be to try and fool MS S&T into thinking
the key already exists and hence that there is no need to try and re-add
it. The success of this would depend on how thoroughly it checks that
the ShellNew key has been correctly added.

So, for example you could delete just the subvalue of ShellNew, which
might be 'NullFile', (or 'config', 'filename', 'command', 'data' ).
After opening the New menu a couple of times, the entry should have
disappeared. That *may* be sufficient to fool the program into thinking
that the key already exists and hence that there is no need to re-add
it, when the program is run. I don't use the program myself, so I can't
test it.

Other possibilities might include (assuming an 'xyz' extension for MS
S&T and that the value of the "(default)" key at
HKEY_LOCAL_MACHINE\SOFTWARE\Classes\.xyz is 'xyzdefaultvalue' )


(1) Open up the text for the '(default)' key at
HKEY_LOCAL_MACHINE\SOFTWARE\Classes\xyzdefaultvalue
and remove the text (ie double-click it, remove the text and close it)

[NB Don't remove the text for the '(default)' value at
HKEY_LOCAL_MACHINE\SOFTWARE\Classes\xyz ]

OR

(2) Delete this key if it exists and also do step (1)
HKEY_LOCAL_MACHINE\SOFTWARE\Classes\xyzdefaultvalue\FriendlyTypeName

[NB Make suitable exports of the above registry keys, if you wish to
restore them to their original condition later. ]


Jon


For **every** other Microsoft program (e. g. Word, Excel, PowerPoint,
etc., and others like Adobe Reader, when clicking on the document
template in TweakUI to remove the checkmark, the utility renames the
Shellnew key to Shellnew-. This ends the process of adding the
application to the context menu under "New." However for MS Streets and
Trips, TweakUI actually deletes the key. If I manually rename the key
to Shellnew- in the registry, MS streets and Trips adds a new Shellnew
key adjacent to the renamed Shellnew- key as you have stated below.

I was hoping to find a way to keep the MS S&T application from adding a
new key each time it opens. That hope is becoming the impossible dream.
I guess it is time to say, "uncle."




....... I have been using TweakUI to handle
the problem ..............

.......Those keys can be controlled with an entry which will
determine true(1) or
false(0) and I needed to know how to implement the modification. It
seems
that no one seems to have that knowledge at this newsgroup, or they
are remaining
silent.


Ok, I can see now how you may have gained the impression from TweakUI
that there is a simple on /off switch for 'New menu' entries.

What TweakUI does, when toggling the New menu entry between enabled
and disabled, is to rename the aforementioned 'ShellNew' key, *for a
particular extension* to 'ShellNew-', (ie it puts a hyphen on the end
of it). - thus rendering the registry entry , *for that particular
extension only* invalid.

eg for an extension, say xyz,

HKEY_LOCAL_MACHINE\SOFTWARE\Classes\.xyz\ShellNew
[or what is the same
HKEY_CLASSES_ROOT\.xyz\ShellNew ]
it is renamed to
HKEY_LOCAL_MACHINE\SOFTWARE\Classes\.xyz\ShellNew-

To delete the entry it removes the ShellNew key entirely.

When you run TweakUI, as well as noting 'ShellNew' keys, it also
highlights the 'ShellNew-' keys, and presents them to you as disabled
forms of the previous.

However, it would be a simple matter for a program to readd a
legitimate 'ShellNew' key, which is what you are observing.


Jon

 

[Jon]

This may do the trick....

This particular registry key holds what is *currently* displayed in the New
menu, so removing relevant permissions on the key can stop anything new from
being added.

HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\Discardable\PostSetup\ShellNew

[Set a Restore point, as precaution, which would reverse the following]

Navigate to the key, and right-click > Delete any entries in the right
pane, that you wish to remove, such as the Streets & Trips entry

Right-click the "ShellNew" key in the left pane, for the above key >
Permissions > Advanced
Uncheck the "Inherit from parent....." and then choose "Copy" (not "Remove")

Then right-click the key > Permissions and uncheck the "Full Control" for
each category (Administrators, System etc), leaving the "Read" option
checked.

[NB Might also be a good idea to note the current permission settings on the
key, for the various categories, should you wish to make changes in the
future, or reverse the process, without resorting to System Restore etc]


--
Jon

Give us the tools and we will finish the job
--Winston Churchill

I have had no luck "fooling" the MS S&T. Any alterations provokes the
program to re-write the registry key. I feel certain that there is a method
to achieve what I am needing, but I am at a loss as to what it would be.
Thanks for all of your help and suggestions.

No problem - I've got the thread bookmarked.

--
Jon

Where is the wisdom we have lost in knowledge?
Where is the knowledge we have lost in information?

- T.S. Elliot

Jon, I have been camping since Wednesday and just returned home. I will
give your suggestions a try, and get back to you with the results.


An alternative approach would be to try and fool MS S&T into thinking
the key already exists and hence that there is no need to try and
re-add it. The success of this would depend on how thoroughly it checks
that the ShellNew key has been correctly added.

So, for example you could delete just the subvalue of ShellNew, which
might be 'NullFile', (or 'config', 'filename', 'command', 'data' ).
After opening the New menu a couple of times, the entry should have
disappeared. That *may* be sufficient to fool the program into thinking
that the key already exists and hence that there is no need to re-add
it, when the program is run. I don't use the program myself, so I can't
test it.

Other possibilities might include (assuming an 'xyz' extension for MS
S&T and that the value of the "(default)" key at
HKEY_LOCAL_MACHINE\SOFTWARE\Classes\.xyz is 'xyzdefaultvalue' )


(1) Open up the text for the '(default)' key at
HKEY_LOCAL_MACHINE\SOFTWARE\Classes\xyzdefaultvalue
and remove the text (ie double-click it, remove the text and close it)

[NB Don't remove the text for the '(default)' value at
HKEY_LOCAL_MACHINE\SOFTWARE\Classes\xyz ]

OR

(2) Delete this key if it exists and also do step (1)
HKEY_LOCAL_MACHINE\SOFTWARE\Classes\xyzdefaultvalue\FriendlyTypeName

[NB Make suitable exports of the above registry keys, if you wish to
restore them to their original condition later. ]


Jon


For **every** other Microsoft program (e. g. Word, Excel, PowerPoint,
etc., and others like Adobe Reader, when clicking on the document
template in TweakUI to remove the checkmark, the utility renames the
Shellnew key to Shellnew-. This ends the process of adding the
application to the context menu under "New." However for MS Streets
and Trips, TweakUI actually deletes the key. If I manually rename the
key to Shellnew- in the registry, MS streets and Trips adds a new
Shellnew key adjacent to the renamed Shellnew- key as you have stated
below.

I was hoping to find a way to keep the MS S&T application from adding
a new key each time it opens. That hope is becoming the impossible
dream. I guess it is time to say, "uncle."




....... I have been using TweakUI to handle
the problem ..............

.......Those keys can be controlled with an entry which will
determine true(1) or
false(0) and I needed to know how to implement the modification. It
seems
that no one seems to have that knowledge at this newsgroup, or they
are remaining
silent.


Ok, I can see now how you may have gained the impression from TweakUI
that there is a simple on /off switch for 'New menu' entries.

What TweakUI does, when toggling the New menu entry between enabled
and disabled, is to rename the aforementioned 'ShellNew' key, *for a
particular extension* to 'ShellNew-', (ie it puts a hyphen on the end
of it). - thus rendering the registry entry , *for that particular
extension only* invalid.

eg for an extension, say xyz,

HKEY_LOCAL_MACHINE\SOFTWARE\Classes\.xyz\ShellNew
[or what is the same
HKEY_CLASSES_ROOT\.xyz\ShellNew ]
it is renamed to
HKEY_LOCAL_MACHINE\SOFTWARE\Classes\.xyz\ShellNew-

To delete the entry it removes the ShellNew key entirely.

When you run TweakUI, as well as noting 'ShellNew' keys, it also
highlights the 'ShellNew-' keys, and presents them to you as disabled
forms of the previous.

However, it would be a simple matter for a program to readd a
legitimate 'ShellNew' key, which is what you are observing.


Jon

 

[J]

NB Right-clicking the key and choosing permissions > Advanced > [Rechecking
the 'Inherit..." box] > ok
can reverse the process

--
Jon

Give us the tools and we will finish the job
--Winston Churchill

This may do the trick....

This particular registry key holds what is *currently* displayed in the
New menu, so removing relevant permissions on the key can stop anything
new from being added.

HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\Discardable\PostSetup\ShellNew

[Set a Restore point, as precaution, which would reverse the following]

Navigate to the key, and right-click > Delete any entries in the right
pane, that you wish to remove, such as the Streets & Trips entry

Right-click the "ShellNew" key in the left pane, for the above key >
Permissions > Advanced
Uncheck the "Inherit from parent....." and then choose "Copy" (not
"Remove")

Then right-click the key > Permissions and uncheck the "Full Control" for
each category (Administrators, System etc), leaving the "Read" option
checked.

[NB Might also be a good idea to note the current permission settings on
the key, for the various categories, should you wish to make changes in
the future, or reverse the process, without resorting to System Restore
etc]


--
Jon

Give us the tools and we will finish the job
--Winston Churchill

I have had no luck "fooling" the MS S&T. Any alterations provokes the
program to re-write the registry key. I feel certain that there is a
method to achieve what I am needing, but I am at a loss as to what it
would be. Thanks for all of your help and suggestions.

No problem - I've got the thread bookmarked.

--
Jon

Where is the wisdom we have lost in knowledge?
Where is the knowledge we have lost in information?

- T.S. Elliot

Jon, I have been camping since Wednesday and just returned home. I will
give your suggestions a try, and get back to you with the results.


An alternative approach would be to try and fool MS S&T into thinking
the key already exists and hence that there is no need to try and
re-add it. The success of this would depend on how thoroughly it
checks that the ShellNew key has been correctly added.

So, for example you could delete just the subvalue of ShellNew, which
might be 'NullFile', (or 'config', 'filename', 'command', 'data' ).
After opening the New menu a couple of times, the entry should have
disappeared. That *may* be sufficient to fool the program into
thinking that the key already exists and hence that there is no need
to re-add it, when the program is run. I don't use the program myself,
so I can't test it.

Other possibilities might include (assuming an 'xyz' extension for MS
S&T and that the value of the "(default)" key at
HKEY_LOCAL_MACHINE\SOFTWARE\Classes\.xyz is 'xyzdefaultvalue' )


(1) Open up the text for the '(default)' key at
HKEY_LOCAL_MACHINE\SOFTWARE\Classes\xyzdefaultvalue
and remove the text (ie double-click it, remove the text and close it)

[NB Don't remove the text for the '(default)' value at
HKEY_LOCAL_MACHINE\SOFTWARE\Classes\xyz ]

OR

(2) Delete this key if it exists and also do step (1)
HKEY_LOCAL_MACHINE\SOFTWARE\Classes\xyzdefaultvalue\FriendlyTypeName

[NB Make suitable exports of the above registry keys, if you wish to
restore them to their original condition later. ]


Jon


For **every** other Microsoft program (e. g. Word, Excel, PowerPoint,
etc., and others like Adobe Reader, when clicking on the document
template in TweakUI to remove the checkmark, the utility renames the
Shellnew key to Shellnew-. This ends the process of adding the
application to the context menu under "New." However for MS Streets
and Trips, TweakUI actually deletes the key. If I manually rename the
key to Shellnew- in the registry, MS streets and Trips adds a new
Shellnew key adjacent to the renamed Shellnew- key as you have stated
below.

I was hoping to find a way to keep the MS S&T application from adding
a new key each time it opens. That hope is becoming the impossible
dream. I guess it is time to say, "uncle."




....... I have been using TweakUI to handle
the problem ..............

.......Those keys can be controlled with an entry which will
determine true(1) or
false(0) and I needed to know how to implement the modification. It
seems
that no one seems to have that knowledge at this newsgroup, or they
are remaining
silent.


Ok, I can see now how you may have gained the impression from
TweakUI that there is a simple on /off switch for 'New menu'
entries.

What TweakUI does, when toggling the New menu entry between enabled
and disabled, is to rename the aforementioned 'ShellNew' key, *for
a particular extension* to 'ShellNew-', (ie it puts a hyphen on the
end of it). - thus rendering the registry entry , *for that
particular extension only* invalid.

eg for an extension, say xyz,

HKEY_LOCAL_MACHINE\SOFTWARE\Classes\.xyz\ShellNew
[or what is the same
HKEY_CLASSES_ROOT\.xyz\ShellNew ]
it is renamed to
HKEY_LOCAL_MACHINE\SOFTWARE\Classes\.xyz\ShellNew-

To delete the entry it removes the ShellNew key entirely.

When you run TweakUI, as well as noting 'ShellNew' keys, it also
highlights the 'ShellNew-' keys, and presents them to you as
disabled forms of the previous.

However, it would be a simple matter for a program to readd a
legitimate 'ShellNew' key, which is what you are observing.


Jon

 

[P. H. Allen]

Jon, There are two entries for this key. One is under HKEY_CURRENT_USER and
the second one is under HKEY_USERS. When I do as you instructed in the order
you presented below, the entire key is replicated as soon as I complete the
last check removal under permissions. I started at HKEY_CURRENT_USER first,
and after observing this phenomenon, I started with the key under
HKEY_USERS. It makes no difference where I start, the key is immediately
replicated upon un-checking the last box under permissions. After the key is
replicated, I am unable to delete the reference to Microsoft Streets and
Trips Map on the right hand pane. Weird doesn't even begin to describe this
annoyance.

This may do the trick....

This particular registry key holds what is *currently* displayed in the
New menu, so removing relevant permissions on the key can stop anything
new from being added.

HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\Discardable\PostSetup\ShellNew

[Set a Restore point, as precaution, which would reverse the following]

Navigate to the key, and right-click > Delete any entries in the right
pane, that you wish to remove, such as the Streets & Trips entry

Right-click the "ShellNew" key in the left pane, for the above key >
Permissions > Advanced
Uncheck the "Inherit from parent....." and then choose "Copy" (not
"Remove")

Then right-click the key > Permissions and uncheck the "Full Control" for
each category (Administrators, System etc), leaving the "Read" option
checked.

[NB Might also be a good idea to note the current permission settings on
the key, for the various categories, should you wish to make changes in
the future, or reverse the process, without resorting to System Restore
etc]


--
Jon

Give us the tools and we will finish the job
--Winston Churchill

I have had no luck "fooling" the MS S&T. Any alterations provokes the
program to re-write the registry key. I feel certain that there is a
method to achieve what I am needing, but I am at a loss as to what it
would be. Thanks for all of your help and suggestions.

No problem - I've got the thread bookmarked.

--
Jon

Where is the wisdom we have lost in knowledge?
Where is the knowledge we have lost in information?

- T.S. Elliot

Jon, I have been camping since Wednesday and just returned home. I will
give your suggestions a try, and get back to you with the results.


An alternative approach would be to try and fool MS S&T into thinking
the key already exists and hence that there is no need to try and
re-add it. The success of this would depend on how thoroughly it
checks that the ShellNew key has been correctly added.

So, for example you could delete just the subvalue of ShellNew, which
might be 'NullFile', (or 'config', 'filename', 'command', 'data' ).
After opening the New menu a couple of times, the entry should have
disappeared. That *may* be sufficient to fool the program into
thinking that the key already exists and hence that there is no need
to re-add it, when the program is run. I don't use the program myself,
so I can't test it.

Other possibilities might include (assuming an 'xyz' extension for MS
S&T and that the value of the "(default)" key at
HKEY_LOCAL_MACHINE\SOFTWARE\Classes\.xyz is 'xyzdefaultvalue' )


(1) Open up the text for the '(default)' key at
HKEY_LOCAL_MACHINE\SOFTWARE\Classes\xyzdefaultvalue
and remove the text (ie double-click it, remove the text and close it)

[NB Don't remove the text for the '(default)' value at
HKEY_LOCAL_MACHINE\SOFTWARE\Classes\xyz ]

OR

(2) Delete this key if it exists and also do step (1)
HKEY_LOCAL_MACHINE\SOFTWARE\Classes\xyzdefaultvalue\FriendlyTypeName

[NB Make suitable exports of the above registry keys, if you wish to
restore them to their original condition later. ]


Jon


For **every** other Microsoft program (e. g. Word, Excel, PowerPoint,
etc., and others like Adobe Reader, when clicking on the document
template in TweakUI to remove the checkmark, the utility renames the
Shellnew key to Shellnew-. This ends the process of adding the
application to the context menu under "New." However for MS Streets
and Trips, TweakUI actually deletes the key. If I manually rename the
key to Shellnew- in the registry, MS streets and Trips adds a new
Shellnew key adjacent to the renamed Shellnew- key as you have stated
below.

I was hoping to find a way to keep the MS S&T application from adding
a new key each time it opens. That hope is becoming the impossible
dream. I guess it is time to say, "uncle."




....... I have been using TweakUI to handle
the problem ..............

.......Those keys can be controlled with an entry which will
determine true(1) or
false(0) and I needed to know how to implement the modification. It
seems
that no one seems to have that knowledge at this newsgroup, or they
are remaining
silent.


Ok, I can see now how you may have gained the impression from
TweakUI that there is a simple on /off switch for 'New menu'
entries.

What TweakUI does, when toggling the New menu entry between enabled
and disabled, is to rename the aforementioned 'ShellNew' key, *for
a particular extension* to 'ShellNew-', (ie it puts a hyphen on the
end of it). - thus rendering the registry entry , *for that
particular extension only* invalid.

eg for an extension, say xyz,

HKEY_LOCAL_MACHINE\SOFTWARE\Classes\.xyz\ShellNew
[or what is the same
HKEY_CLASSES_ROOT\.xyz\ShellNew ]
it is renamed to
HKEY_LOCAL_MACHINE\SOFTWARE\Classes\.xyz\ShellNew-

To delete the entry it removes the ShellNew key entirely.

When you run TweakUI, as well as noting 'ShellNew' keys, it also
highlights the 'ShellNew-' keys, and presents them to you as
disabled forms of the previous.

However, it would be a simple matter for a program to readd a
legitimate 'ShellNew' key, which is what you are observing.


Jon

 

[Jon]

Odd . Ensure that you've unchecked the "Full Control" setting for *all*
users listed in the permissions box for that ShellNew key,even your own
Administrator account, before clicking ok and closing Regedit - otherwise
once you close up regedit it will be re-added, as you say.

To delete the entries in the right pane, you will need to re-check the "Full
control" setting for your own account, (depending on the error message of
course).

Closing any instances of MS S&T currently open may also help and / or trying
it in Safe mode.

If none of that works, then yes, something pretty weird is going on.


--
Jon

You never know what you can do till you try

Jon, There are two entries for this key. One is under HKEY_CURRENT_USER
and the second one is under HKEY_USERS. When I do as you instructed in the
order you presented below, the entire key is replicated as soon as I
complete the last check removal under permissions. I started at
HKEY_CURRENT_USER first, and after observing this phenomenon, I started
with the key under HKEY_USERS. It makes no difference where I start, the
key is immediately replicated upon un-checking the last box under
permissions. After the key is replicated, I am unable to delete the
reference to Microsoft Streets and Trips Map on the right hand pane. Weird
doesn't even begin to describe this annoyance.

This may do the trick....

This particular registry key holds what is *currently* displayed in the
New menu, so removing relevant permissions on the key can stop anything
new from being added.

HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\Discardable\PostSetup\ShellNew

[Set a Restore point, as precaution, which would reverse the following]

Navigate to the key, and right-click > Delete any entries in the right
pane, that you wish to remove, such as the Streets & Trips entry

Right-click the "ShellNew" key in the left pane, for the above key >
Permissions > Advanced
Uncheck the "Inherit from parent....." and then choose "Copy" (not
"Remove")

Then right-click the key > Permissions and uncheck the "Full Control" for
each category (Administrators, System etc), leaving the "Read" option
checked.

[NB Might also be a good idea to note the current permission settings on
the key, for the various categories, should you wish to make changes in
the future, or reverse the process, without resorting to System Restore
etc]


--
Jon

Give us the tools and we will finish the job
--Winston Churchill

I have had no luck "fooling" the MS S&T. Any alterations provokes the
program to re-write the registry key. I feel certain that there is a
method to achieve what I am needing, but I am at a loss as to what it
would be. Thanks for all of your help and suggestions.

No problem - I've got the thread bookmarked.

--
Jon

Where is the wisdom we have lost in knowledge?
Where is the knowledge we have lost in information?

- T.S. Elliot

Jon, I have been camping since Wednesday and just returned home. I
will give your suggestions a try, and get back to you with the
results.


An alternative approach would be to try and fool MS S&T into thinking
the key already exists and hence that there is no need to try and
re-add it. The success of this would depend on how thoroughly it
checks that the ShellNew key has been correctly added.

So, for example you could delete just the subvalue of ShellNew, which
might be 'NullFile', (or 'config', 'filename', 'command', 'data' ).
After opening the New menu a couple of times, the entry should have
disappeared. That *may* be sufficient to fool the program into
thinking that the key already exists and hence that there is no need
to re-add it, when the program is run. I don't use the program
myself, so I can't test it.

Other possibilities might include (assuming an 'xyz' extension for MS
S&T and that the value of the "(default)" key at
HKEY_LOCAL_MACHINE\SOFTWARE\Classes\.xyz is 'xyzdefaultvalue' )


(1) Open up the text for the '(default)' key at
HKEY_LOCAL_MACHINE\SOFTWARE\Classes\xyzdefaultvalue
and remove the text (ie double-click it, remove the text and close
it)

[NB Don't remove the text for the '(default)' value at
HKEY_LOCAL_MACHINE\SOFTWARE\Classes\xyz ]

OR

(2) Delete this key if it exists and also do step (1)
HKEY_LOCAL_MACHINE\SOFTWARE\Classes\xyzdefaultvalue\FriendlyTypeName

[NB Make suitable exports of the above registry keys, if you wish to
restore them to their original condition later. ]


Jon


For **every** other Microsoft program (e. g. Word, Excel,
PowerPoint, etc., and others like Adobe Reader, when clicking on the
document template in TweakUI to remove the checkmark, the utility
renames the Shellnew key to Shellnew-. This ends the process of
adding the application to the context menu under "New." However for
MS Streets and Trips, TweakUI actually deletes the key. If I
manually rename the key to Shellnew- in the registry, MS streets and
Trips adds a new Shellnew key adjacent to the renamed Shellnew- key
as you have stated below.

I was hoping to find a way to keep the MS S&T application from
adding a new key each time it opens. That hope is becoming the
impossible dream. I guess it is time to say, "uncle."




....... I have been using TweakUI to handle
the problem ..............

.......Those keys can be controlled with an entry which will
determine true(1) or
false(0) and I needed to know how to implement the modification.
It seems
that no one seems to have that knowledge at this newsgroup, or
they are remaining
silent.


Ok, I can see now how you may have gained the impression from
TweakUI that there is a simple on /off switch for 'New menu'
entries.

What TweakUI does, when toggling the New menu entry between enabled
and disabled, is to rename the aforementioned 'ShellNew' key, *for
a particular extension* to 'ShellNew-', (ie it puts a hyphen on the
end of it). - thus rendering the registry entry , *for that
particular extension only* invalid.

eg for an extension, say xyz,

HKEY_LOCAL_MACHINE\SOFTWARE\Classes\.xyz\ShellNew
[or what is the same
HKEY_CLASSES_ROOT\.xyz\ShellNew ]
it is renamed to
HKEY_LOCAL_MACHINE\SOFTWARE\Classes\.xyz\ShellNew-

To delete the entry it removes the ShellNew key entirely.

When you run TweakUI, as well as noting 'ShellNew' keys, it also
highlights the 'ShellNew-' keys, and presents them to you as
disabled forms of the previous.

However, it would be a simple matter for a program to readd a
legitimate 'ShellNew' key, which is what you are observing.


Jon

 

[Jon]

NB The two registry locations are the same place, the
HKEY_CURRENT_USER being just an abbreviation for the extended
HKEY_USERS.....form


--
Jon

Two dogs fight for a bone, and a third runs away with it

Odd . Ensure that you've unchecked the "Full Control" setting for *all*
users listed in the permissions box for that ShellNew key,even your own
Administrator account, before clicking ok and closing Regedit - otherwise
once you close up regedit it will be re-added, as you say.

To delete the entries in the right pane, you will need to re-check the
"Full control" setting for your own account, (depending on the error
message of course).

Closing any instances of MS S&T currently open may also help and / or
trying it in Safe mode.

If none of that works, then yes, something pretty weird is going on.


--
Jon

You never know what you can do till you try

Jon, There are two entries for this key. One is under HKEY_CURRENT_USER
and the second one is under HKEY_USERS. When I do as you instructed in
the order you presented below, the entire key is replicated as soon as I
complete the last check removal under permissions. I started at
HKEY_CURRENT_USER first, and after observing this phenomenon, I started
with the key under HKEY_USERS. It makes no difference where I start, the
key is immediately replicated upon un-checking the last box under
permissions. After the key is replicated, I am unable to delete the
reference to Microsoft Streets and Trips Map on the right hand pane.
Weird doesn't even begin to describe this annoyance.

This may do the trick....

This particular registry key holds what is *currently* displayed in the
New menu, so removing relevant permissions on the key can stop anything
new from being added.

HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\Discardable\PostSetup\ShellNew

[Set a Restore point, as precaution, which would reverse the following]

Navigate to the key, and right-click > Delete any entries in the right
pane, that you wish to remove, such as the Streets & Trips entry

Right-click the "ShellNew" key in the left pane, for the above key >
Permissions > Advanced
Uncheck the "Inherit from parent....." and then choose "Copy" (not
"Remove")

Then right-click the key > Permissions and uncheck the "Full Control"
for each category (Administrators, System etc), leaving the "Read"
option checked.

[NB Might also be a good idea to note the current permission settings on
the key, for the various categories, should you wish to make changes in
the future, or reverse the process, without resorting to System Restore
etc]


--
Jon

Give us the tools and we will finish the job
--Winston Churchill

I have had no luck "fooling" the MS S&T. Any alterations provokes the
program to re-write the registry key. I feel certain that there is a
method to achieve what I am needing, but I am at a loss as to what it
would be. Thanks for all of your help and suggestions.

No problem - I've got the thread bookmarked.

--
Jon

Where is the wisdom we have lost in knowledge?
Where is the knowledge we have lost in information?

- T.S. Elliot

Jon, I have been camping since Wednesday and just returned home. I
will give your suggestions a try, and get back to you with the
results.


An alternative approach would be to try and fool MS S&T into
thinking the key already exists and hence that there is no need to
try and re-add it. The success of this would depend on how
thoroughly it checks that the ShellNew key has been correctly added.

So, for example you could delete just the subvalue of ShellNew,
which might be 'NullFile', (or 'config', 'filename', 'command',
'data' ). After opening the New menu a couple of times, the entry
should have disappeared. That *may* be sufficient to fool the
program into thinking that the key already exists and hence that
there is no need to re-add it, when the program is run. I don't use
the program myself, so I can't test it.

Other possibilities might include (assuming an 'xyz' extension for
MS S&T and that the value of the "(default)" key at
HKEY_LOCAL_MACHINE\SOFTWARE\Classes\.xyz is 'xyzdefaultvalue' )


(1) Open up the text for the '(default)' key at
HKEY_LOCAL_MACHINE\SOFTWARE\Classes\xyzdefaultvalue
and remove the text (ie double-click it, remove the text and close
it)

[NB Don't remove the text for the '(default)' value at
HKEY_LOCAL_MACHINE\SOFTWARE\Classes\xyz ]

OR

(2) Delete this key if it exists and also do step (1)
HKEY_LOCAL_MACHINE\SOFTWARE\Classes\xyzdefaultvalue\FriendlyTypeName

[NB Make suitable exports of the above registry keys, if you wish to
restore them to their original condition later. ]


Jon


For **every** other Microsoft program (e. g. Word, Excel,
PowerPoint, etc., and others like Adobe Reader, when clicking on
the document template in TweakUI to remove the checkmark, the
utility renames the Shellnew key to Shellnew-. This ends the
process of adding the application to the context menu under "New."
However for MS Streets and Trips, TweakUI actually deletes the key.
If I manually rename the key to Shellnew- in the registry, MS
streets and Trips adds a new Shellnew key adjacent to the renamed
Shellnew- key as you have stated below.

I was hoping to find a way to keep the MS S&T application from
adding a new key each time it opens. That hope is becoming the
impossible dream. I guess it is time to say, "uncle."




....... I have been using TweakUI to handle
the problem ..............

.......Those keys can be controlled with an entry which will
determine true(1) or
false(0) and I needed to know how to implement the modification.
It seems
that no one seems to have that knowledge at this newsgroup, or
they are remaining
silent.


Ok, I can see now how you may have gained the impression from
TweakUI that there is a simple on /off switch for 'New menu'
entries.

What TweakUI does, when toggling the New menu entry between
enabled and disabled, is to rename the aforementioned 'ShellNew'
key, *for a particular extension* to 'ShellNew-', (ie it puts a
hyphen on the end of it). - thus rendering the registry entry ,
*for that particular extension only* invalid.

eg for an extension, say xyz,

HKEY_LOCAL_MACHINE\SOFTWARE\Classes\.xyz\ShellNew
[or what is the same
HKEY_CLASSES_ROOT\.xyz\ShellNew ]
it is renamed to
HKEY_LOCAL_MACHINE\SOFTWARE\Classes\.xyz\ShellNew-

To delete the entry it removes the ShellNew key entirely.

When you run TweakUI, as well as noting 'ShellNew' keys, it also
highlights the 'ShellNew-' keys, and presents them to you as
disabled forms of the previous.

However, it would be a simple matter for a program to readd a
legitimate 'ShellNew' key, which is what you are observing.


Jon

 

[Jon]

That probably wasn't clear. There are a number of locations in the registry,
which while appearing to be at a different location, are in fact the same
place. Another one is
HKEY_CLASSES_ROOT, which is the same as
HKEY_LOCAL_MACHINE\SOFTWARE\Classes

--
Jon

"How much does Windows cost, and do you have to buy each one separately?"

NB The two registry locations are the same place, the
HKEY_CURRENT_USER being just an abbreviation for the extended
HKEY_USERS.....form


--
Jon

Two dogs fight for a bone, and a third runs away with it

Odd . Ensure that you've unchecked the "Full Control" setting for *all*
users listed in the permissions box for that ShellNew key,even your own
Administrator account, before clicking ok and closing Regedit - otherwise
once you close up regedit it will be re-added, as you say.

To delete the entries in the right pane, you will need to re-check the
"Full control" setting for your own account, (depending on the error
message of course).

Closing any instances of MS S&T currently open may also help and / or
trying it in Safe mode.

If none of that works, then yes, something pretty weird is going on.


--
Jon

You never know what you can do till you try

Jon, There are two entries for this key. One is under HKEY_CURRENT_USER
and the second one is under HKEY_USERS. When I do as you instructed in
the order you presented below, the entire key is replicated as soon as I
complete the last check removal under permissions. I started at
HKEY_CURRENT_USER first, and after observing this phenomenon, I started
with the key under HKEY_USERS. It makes no difference where I start, the
key is immediately replicated upon un-checking the last box under
permissions. After the key is replicated, I am unable to delete the
reference to Microsoft Streets and Trips Map on the right hand pane.
Weird doesn't even begin to describe this annoyance.

This may do the trick....

This particular registry key holds what is *currently* displayed in the
New menu, so removing relevant permissions on the key can stop anything
new from being added.

HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\Discardable\PostSetup\ShellNew

[Set a Restore point, as precaution, which would reverse the following]

Navigate to the key, and right-click > Delete any entries in the right
pane, that you wish to remove, such as the Streets & Trips entry

Right-click the "ShellNew" key in the left pane, for the above key >
Permissions > Advanced
Uncheck the "Inherit from parent....." and then choose "Copy" (not
"Remove")

Then right-click the key > Permissions and uncheck the "Full Control"
for each category (Administrators, System etc), leaving the "Read"
option checked.

[NB Might also be a good idea to note the current permission settings
on the key, for the various categories, should you wish to make changes
in the future, or reverse the process, without resorting to System
Restore etc]


--
Jon

Give us the tools and we will finish the job
--Winston Churchill

I have had no luck "fooling" the MS S&T. Any alterations provokes the
program to re-write the registry key. I feel certain that there is a
method to achieve what I am needing, but I am at a loss as to what it
would be. Thanks for all of your help and suggestions.

No problem - I've got the thread bookmarked.

--
Jon

Where is the wisdom we have lost in knowledge?
Where is the knowledge we have lost in information?

- T.S. Elliot

Jon, I have been camping since Wednesday and just returned home. I
will give your suggestions a try, and get back to you with the
results.


An alternative approach would be to try and fool MS S&T into
thinking the key already exists and hence that there is no need to
try and re-add it. The success of this would depend on how
thoroughly it checks that the ShellNew key has been correctly
added.

So, for example you could delete just the subvalue of ShellNew,
which might be 'NullFile', (or 'config', 'filename', 'command',
'data' ). After opening the New menu a couple of times, the entry
should have disappeared. That *may* be sufficient to fool the
program into thinking that the key already exists and hence that
there is no need to re-add it, when the program is run. I don't use
the program myself, so I can't test it.

Other possibilities might include (assuming an 'xyz' extension for
MS S&T and that the value of the "(default)" key at
HKEY_LOCAL_MACHINE\SOFTWARE\Classes\.xyz is 'xyzdefaultvalue' )


(1) Open up the text for the '(default)' key at
HKEY_LOCAL_MACHINE\SOFTWARE\Classes\xyzdefaultvalue
and remove the text (ie double-click it, remove the text and close
it)

[NB Don't remove the text for the '(default)' value at
HKEY_LOCAL_MACHINE\SOFTWARE\Classes\xyz ]

OR

(2) Delete this key if it exists and also do step (1)
HKEY_LOCAL_MACHINE\SOFTWARE\Classes\xyzdefaultvalue\FriendlyTypeName

[NB Make suitable exports of the above registry keys, if you wish
to restore them to their original condition later. ]


Jon


For **every** other Microsoft program (e. g. Word, Excel,
PowerPoint, etc., and others like Adobe Reader, when clicking on
the document template in TweakUI to remove the checkmark, the
utility renames the Shellnew key to Shellnew-. This ends the
process of adding the application to the context menu under "New."
However for MS Streets and Trips, TweakUI actually deletes the
key. If I manually rename the key to Shellnew- in the registry, MS
streets and Trips adds a new Shellnew key adjacent to the renamed
Shellnew- key as you have stated below.

I was hoping to find a way to keep the MS S&T application from
adding a new key each time it opens. That hope is becoming the
impossible dream. I guess it is time to say, "uncle."




....... I have been using TweakUI to handle
the problem ..............

.......Those keys can be controlled with an entry which will
determine true(1) or
false(0) and I needed to know how to implement the modification.
It seems
that no one seems to have that knowledge at this newsgroup, or
they are remaining
silent.


Ok, I can see now how you may have gained the impression from
TweakUI that there is a simple on /off switch for 'New menu'
entries.

What TweakUI does, when toggling the New menu entry between
enabled and disabled, is to rename the aforementioned 'ShellNew'
key, *for a particular extension* to 'ShellNew-', (ie it puts a
hyphen on the end of it). - thus rendering the registry entry ,
*for that particular extension only* invalid.

eg for an extension, say xyz,

HKEY_LOCAL_MACHINE\SOFTWARE\Classes\.xyz\ShellNew
[or what is the same
HKEY_CLASSES_ROOT\.xyz\ShellNew ]
it is renamed to
HKEY_LOCAL_MACHINE\SOFTWARE\Classes\.xyz\ShellNew-

To delete the entry it removes the ShellNew key entirely.

When you run TweakUI, as well as noting 'ShellNew' keys, it also
highlights the 'ShellNew-' keys, and presents them to you as
disabled forms of the previous.

However, it would be a simple matter for a program to readd a
legitimate 'ShellNew' key, which is what you are observing.


Jon

 

[P. H. Allen]

Jon, I executed *exactly* as you described in your email. I even repeated
the process several times to be certain that I had completed the process
properly. After removing the last checkmark, the reference to MS S&T
instantly appears that had previously been deleted. I will boot to the safe
mode and will execute the process. I will advise you of the outcome.

Odd . Ensure that you've unchecked the "Full Control" setting for *all*
users listed in the permissions box for that ShellNew key,even your own
Administrator account, before clicking ok and closing Regedit - otherwise
once you close up regedit it will be re-added, as you say.

To delete the entries in the right pane, you will need to re-check the
"Full control" setting for your own account, (depending on the error
message of course).

Closing any instances of MS S&T currently open may also help and / or
trying it in Safe mode.

If none of that works, then yes, something pretty weird is going on.


--
Jon

You never know what you can do till you try

Jon, There are two entries for this key. One is under HKEY_CURRENT_USER
and the second one is under HKEY_USERS. When I do as you instructed in
the order you presented below, the entire key is replicated as soon as I
complete the last check removal under permissions. I started at
HKEY_CURRENT_USER first, and after observing this phenomenon, I started
with the key under HKEY_USERS. It makes no difference where I start, the
key is immediately replicated upon un-checking the last box under
permissions. After the key is replicated, I am unable to delete the
reference to Microsoft Streets and Trips Map on the right hand pane.
Weird doesn't even begin to describe this annoyance.

This may do the trick....

This particular registry key holds what is *currently* displayed in the
New menu, so removing relevant permissions on the key can stop anything
new from being added.

HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\Discardable\PostSetup\ShellNew

[Set a Restore point, as precaution, which would reverse the following]

Navigate to the key, and right-click > Delete any entries in the right
pane, that you wish to remove, such as the Streets & Trips entry

Right-click the "ShellNew" key in the left pane, for the above key >
Permissions > Advanced
Uncheck the "Inherit from parent....." and then choose "Copy" (not
"Remove")

Then right-click the key > Permissions and uncheck the "Full Control"
for each category (Administrators, System etc), leaving the "Read"
option checked.

[NB Might also be a good idea to note the current permission settings on
the key, for the various categories, should you wish to make changes in
the future, or reverse the process, without resorting to System Restore
etc]


--
Jon

Give us the tools and we will finish the job
--Winston Churchill

I have had no luck "fooling" the MS S&T. Any alterations provokes the
program to re-write the registry key. I feel certain that there is a
method to achieve what I am needing, but I am at a loss as to what it
would be. Thanks for all of your help and suggestions.

No problem - I've got the thread bookmarked.

--
Jon

Where is the wisdom we have lost in knowledge?
Where is the knowledge we have lost in information?

- T.S. Elliot

Jon, I have been camping since Wednesday and just returned home. I
will give your suggestions a try, and get back to you with the
results.


An alternative approach would be to try and fool MS S&T into
thinking the key already exists and hence that there is no need to
try and re-add it. The success of this would depend on how
thoroughly it checks that the ShellNew key has been correctly added.

So, for example you could delete just the subvalue of ShellNew,
which might be 'NullFile', (or 'config', 'filename', 'command',
'data' ). After opening the New menu a couple of times, the entry
should have disappeared. That *may* be sufficient to fool the
program into thinking that the key already exists and hence that
there is no need to re-add it, when the program is run. I don't use
the program myself, so I can't test it.

Other possibilities might include (assuming an 'xyz' extension for
MS S&T and that the value of the "(default)" key at
HKEY_LOCAL_MACHINE\SOFTWARE\Classes\.xyz is 'xyzdefaultvalue' )


(1) Open up the text for the '(default)' key at
HKEY_LOCAL_MACHINE\SOFTWARE\Classes\xyzdefaultvalue
and remove the text (ie double-click it, remove the text and close
it)

[NB Don't remove the text for the '(default)' value at
HKEY_LOCAL_MACHINE\SOFTWARE\Classes\xyz ]

OR

(2) Delete this key if it exists and also do step (1)
HKEY_LOCAL_MACHINE\SOFTWARE\Classes\xyzdefaultvalue\FriendlyTypeName

[NB Make suitable exports of the above registry keys, if you wish to
restore them to their original condition later. ]


Jon


For **every** other Microsoft program (e. g. Word, Excel,
PowerPoint, etc., and others like Adobe Reader, when clicking on
the document template in TweakUI to remove the checkmark, the
utility renames the Shellnew key to Shellnew-. This ends the
process of adding the application to the context menu under "New."
However for MS Streets and Trips, TweakUI actually deletes the key.
If I manually rename the key to Shellnew- in the registry, MS
streets and Trips adds a new Shellnew key adjacent to the renamed
Shellnew- key as you have stated below.

I was hoping to find a way to keep the MS S&T application from
adding a new key each time it opens. That hope is becoming the
impossible dream. I guess it is time to say, "uncle."




....... I have been using TweakUI to handle
the problem ..............

.......Those keys can be controlled with an entry which will
determine true(1) or
false(0) and I needed to know how to implement the modification.
It seems
that no one seems to have that knowledge at this newsgroup, or
they are remaining
silent.


Ok, I can see now how you may have gained the impression from
TweakUI that there is a simple on /off switch for 'New menu'
entries.

What TweakUI does, when toggling the New menu entry between
enabled and disabled, is to rename the aforementioned 'ShellNew'
key, *for a particular extension* to 'ShellNew-', (ie it puts a
hyphen on the end of it). - thus rendering the registry entry ,
*for that particular extension only* invalid.

eg for an extension, say xyz,

HKEY_LOCAL_MACHINE\SOFTWARE\Classes\.xyz\ShellNew
[or what is the same
HKEY_CLASSES_ROOT\.xyz\ShellNew ]
it is renamed to
HKEY_LOCAL_MACHINE\SOFTWARE\Classes\.xyz\ShellNew-

To delete the entry it removes the ShellNew key entirely.

When you run TweakUI, as well as noting 'ShellNew' keys, it also
highlights the 'ShellNew-' keys, and presents them to you as
disabled forms of the previous.

However, it would be a simple matter for a program to readd a
legitimate 'ShellNew' key, which is what you are observing.


Jon

 

[Jon]

...had too many beers watching England qualify for the last 16, to make any
intelligent suggestions tonight, other than perhaps using it as opportunity
to learn / brush up on a bit of assembly language and hack the stupid
registry writing routine out of the program....

--
Jon

It takes all sorts to make a world

Jon, I executed *exactly* as you described in your email. I even repeated
the process several times to be certain that I had completed the process
properly. After removing the last checkmark, the reference to MS S&T
instantly appears that had previously been deleted. I will boot to the
safe mode and will execute the process. I will advise you of the outcome.

Odd . Ensure that you've unchecked the "Full Control" setting for *all*
users listed in the permissions box for that ShellNew key,even your own
Administrator account, before clicking ok and closing Regedit - otherwise
once you close up regedit it will be re-added, as you say.

To delete the entries in the right pane, you will need to re-check the
"Full control" setting for your own account, (depending on the error
message of course).

Closing any instances of MS S&T currently open may also help and / or
trying it in Safe mode.

If none of that works, then yes, something pretty weird is going on.


--
Jon

You never know what you can do till you try

Jon, There are two entries for this key. One is under HKEY_CURRENT_USER
and the second one is under HKEY_USERS. When I do as you instructed in
the order you presented below, the entire key is replicated as soon as I
complete the last check removal under permissions. I started at
HKEY_CURRENT_USER first, and after observing this phenomenon, I started
with the key under HKEY_USERS. It makes no difference where I start, the
key is immediately replicated upon un-checking the last box under
permissions. After the key is replicated, I am unable to delete the
reference to Microsoft Streets and Trips Map on the right hand pane.
Weird doesn't even begin to describe this annoyance.

This may do the trick....

This particular registry key holds what is *currently* displayed in the
New menu, so removing relevant permissions on the key can stop anything
new from being added.

HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\Discardable\PostSetup\ShellNew

[Set a Restore point, as precaution, which would reverse the following]

Navigate to the key, and right-click > Delete any entries in the right
pane, that you wish to remove, such as the Streets & Trips entry

Right-click the "ShellNew" key in the left pane, for the above key >
Permissions > Advanced
Uncheck the "Inherit from parent....." and then choose "Copy" (not
"Remove")

Then right-click the key > Permissions and uncheck the "Full Control"
for each category (Administrators, System etc), leaving the "Read"
option checked.

[NB Might also be a good idea to note the current permission settings
on the key, for the various categories, should you wish to make changes
in the future, or reverse the process, without resorting to System
Restore etc]


--
Jon

Give us the tools and we will finish the job
--Winston Churchill

I have had no luck "fooling" the MS S&T. Any alterations provokes the
program to re-write the registry key. I feel certain that there is a
method to achieve what I am needing, but I am at a loss as to what it
would be. Thanks for all of your help and suggestions.

No problem - I've got the thread bookmarked.

--
Jon

Where is the wisdom we have lost in knowledge?
Where is the knowledge we have lost in information?

- T.S. Elliot

Jon, I have been camping since Wednesday and just returned home. I
will give your suggestions a try, and get back to you with the
results.


An alternative approach would be to try and fool MS S&T into
thinking the key already exists and hence that there is no need to
try and re-add it. The success of this would depend on how
thoroughly it checks that the ShellNew key has been correctly
added.

So, for example you could delete just the subvalue of ShellNew,
which might be 'NullFile', (or 'config', 'filename', 'command',
'data' ). After opening the New menu a couple of times, the entry
should have disappeared. That *may* be sufficient to fool the
program into thinking that the key already exists and hence that
there is no need to re-add it, when the program is run. I don't use
the program myself, so I can't test it.

Other possibilities might include (assuming an 'xyz' extension for
MS S&T and that the value of the "(default)" key at
HKEY_LOCAL_MACHINE\SOFTWARE\Classes\.xyz is 'xyzdefaultvalue' )


(1) Open up the text for the '(default)' key at
HKEY_LOCAL_MACHINE\SOFTWARE\Classes\xyzdefaultvalue
and remove the text (ie double-click it, remove the text and close
it)

[NB Don't remove the text for the '(default)' value at
HKEY_LOCAL_MACHINE\SOFTWARE\Classes\xyz ]

OR

(2) Delete this key if it exists and also do step (1)
HKEY_LOCAL_MACHINE\SOFTWARE\Classes\xyzdefaultvalue\FriendlyTypeName

[NB Make suitable exports of the above registry keys, if you wish
to restore them to their original condition later. ]


Jon


For **every** other Microsoft program (e. g. Word, Excel,
PowerPoint, etc., and others like Adobe Reader, when clicking on
the document template in TweakUI to remove the checkmark, the
utility renames the Shellnew key to Shellnew-. This ends the
process of adding the application to the context menu under "New."
However for MS Streets and Trips, TweakUI actually deletes the
key. If I manually rename the key to Shellnew- in the registry, MS
streets and Trips adds a new Shellnew key adjacent to the renamed
Shellnew- key as you have stated below.

I was hoping to find a way to keep the MS S&T application from
adding a new key each time it opens. That hope is becoming the
impossible dream. I guess it is time to say, "uncle."




....... I have been using TweakUI to handle
the problem ..............

.......Those keys can be controlled with an entry which will
determine true(1) or
false(0) and I needed to know how to implement the modification.
It seems
that no one seems to have that knowledge at this newsgroup, or
they are remaining
silent.


Ok, I can see now how you may have gained the impression from
TweakUI that there is a simple on /off switch for 'New menu'
entries.

What TweakUI does, when toggling the New menu entry between
enabled and disabled, is to rename the aforementioned 'ShellNew'
key, *for a particular extension* to 'ShellNew-', (ie it puts a
hyphen on the end of it). - thus rendering the registry entry ,
*for that particular extension only* invalid.

eg for an extension, say xyz,

HKEY_LOCAL_MACHINE\SOFTWARE\Classes\.xyz\ShellNew
[or what is the same
HKEY_CLASSES_ROOT\.xyz\ShellNew ]
it is renamed to
HKEY_LOCAL_MACHINE\SOFTWARE\Classes\.xyz\ShellNew-

To delete the entry it removes the ShellNew key entirely.

When you run TweakUI, as well as noting 'ShellNew' keys, it also
highlights the 'ShellNew-' keys, and presents them to you as
disabled forms of the previous.

However, it would be a simple matter for a program to readd a
legitimate 'ShellNew' key, which is what you are observing.


Jon