It was always previously possible to "undelete" a deleted menu item by "re-deleting" it. See Inga's article: http://communities.bentley.com/communities/other_communities/askinga/w/askinga/restore-deleted-menu-items-in-microstation-v8-xm-edition.aspx
But now it seems this isn't possible. I have an interface with the File > New... deleted (& replaced with a custom VB tool to create files to company naming standards). However, if I try to restore the menu item, delete is not active.
Am I missing something?
(I can work around the problem by exporting the interface XML, removing the <UserDeleteMenuEntry> entry and reimporting into a new dgnlib, but it would be nice to know why it can't be done through the interface.)
It looks like everything is grayed out - are you in the DGNLIB file that contains that menu item ?
I've had this headache a few times in the past and though I haven't changed my menu entries since upgrading to SS3 I wanted to test if it is indeed broken. The answer short answer is that no, its not broken but because there is no tool-tip popup when you hover of the modified menu entry (as what happens when you hover over a dimension style and the network path of the source DGNLIB is revealed), finding out why this happens is a real nuisance. The reason for the behaviour you see is suggested within the help file:
"When you open or create a DGN file you see all the custom menus in the configured DGN libraries. If several files in the DGN libraries contain menu customizations, you see a union of the menu changes in these files. For example, if FileOne.dgnlib has hidden the Help menu and FileTwo.dgnlib has not hidden it, the Help menu will be hidden."
This behaviour appears to have an undesired reverse effect when it comes to editing menu's but it's because of this that I discovered what causes this issue. The answer is that (as I found in the case of 2 of my GUI-related DGNLIB files) the deleted menu-entry has been made in more than 1 file. After renaming one of these files to DGN (so it wouldn't be processed at startup) and opening the other in the customize dialog, I un-deleted the entries in the file I didn't want the menu modifications to be stored in, then renamed it back to DGNLIB. Now I can open the customize dialog in the correct DGNLIB and make the changes as expected.
Yes, I was in the correct file. No, it wasn't contained in more than one DGNLIB. As I noted, I could export the XML where the delete entry was clear.
I've resolved it by editing the XML and re-creating the dgnlib from a blank seed. I've just put it down to "one of those things".