Delete Menu item from standard Menus

I’m trying to create some custom Standard Menus. I want to delete the “Speech” menu item in the Standard “Edit” Menu. I can delete the 2 sub menus from “Speech” but I can not fiqure out how to delete “Speech”.

I think this will do it.

standardeditmenu("Speech"+tab(),"")

I figured this out by opening the Formula Workshop, and typing in the formula

standardeditmenu()

Scrolling to the bottom of the result, I saw this line:

Speech	(Speech)

I knew that the space between Speech and (Speech) was actually a tab (the character between the menu name and the options will always be a tab). But if you didn’t know that, you could figure it out by using this formula instead,

replace(standardeditmenu(),tab(),"¬")

then the line will look like this:

Speech¬(Speech)

So now I know enough to design an arrayhack to delete the item.

See these topics in the help for more info:

The Formula Workshop is of immense help on this but I’m running into some obstacles in trying to generate a simplified File menu.

Some items like Duplicate, Rename, Move To… don’t show in the workshop, but are present in the database after running standardeditmenu(. I’ve tried a variety of formats, such as +tab() but they persist.

It could be simpler to list desired items for a menu than to strip down the existing menu but I found nothing about proceeding from the opposite direction to indicate which items ti include in the menu.

I’ve run into a similar scenario with the Windows menu. I want to reduce it to just the list of the open windows; available to select and activate.

After eliminating everything I didn’t want in the Formula Workshop I still get Tile Window to Left of Screen,Tile Window to Right of Screen and Enter Full Screen.

The Panorama X menu system is as customizable as it is possible to make it. I don’t believe you will find any other macOS app that is nearly as customizable. Apple really didn’t design the menu system to be fully customizable. There are some components of the menus that are generated “on-the-fly” by Apple’s code - these are the components that you are complaining about not being able to customize. You can include these components in there entirety without modification, or you can exclude them, but you cannot customize these items.

This is a perfect example. These menu items are generated by Apple. If you use an older version of macOS, you won’t see these items. It was quite a feat to allow you to customize the top section of the Window menu while still retaining the Apple generated items at the bottom of the menu (including the list of Windows).

You could completely exclude the Window menu, then build your own from scratch. However I generally wouldn’t recommend doing that, since you would lose the automatic behaviour of these Apple generated menu items.

The File and Edit menus also contain Apple generated items. Again, you could not use the standardfilemenu( and standardeditmenu( functions as the basis for these menus, and build them completely from scratch. But it would be difficult or impossible to exactly mimic the full operation of these menus without using Apple’s code.

This is intentional when using the standard menu functions. The output of these functions can (and does) change as new versions of macOS are released. Apple can and does add new menu items, like the Tile Window items you mention. As far as possible, the Panorama X menu system is designed to be “future proof” so that even though your menus are custom, they still update with new versions of the operating system. That’s why the system of modifying standard menus is in place, so that you can specify how to take the standard menus and customize them, so that your menus will adapt as macOS grows. Of course this can never be 100%, but so far it has allowed Panorama X custom menus to automatically adapt to seven years of macOS menu changes.

Again, if you don’t care about future proofing you can build your menus completely from scratch, but there are some Apple behaviors that cannot be implemented that way.


I think the Panorama X custom menu system is one of the aspects of Panorama X that I am most proud of from a technical perspective. When I started I found online posts on developer forums saying that this kind of customization was impossible. Fortunately I did find a blog that got me started in the right direction, though I ultimately went quite a bit farther than this developer did in regard to menu customization.

http://lapcatsoftware.com/blog/2007/05/16/working-without-a-nib-part-1/

None of this is documented by Apple and quite a bit of it ultimately required intensive sleuthing and reverse engineering. But the end result works great and produced a very flexible system.

It’s hard to guess how many things there are that I’ve built in Panorama after concluding that they couldn’t be built. Persistence, repeatedly reviewing the documentation and sometimes posting for help have all added up to many breakthroughs.

When I reach a point of giving up on my own efforts, I turn to posting on this forum, having already searched it. I relate the objective, my efforts and how the result is falling short of the goal. With all the ways Panorama can accomplish things, it’s not unusual to have overlooked an angle or to have failed to fully understand how a function or procedure can be applied with an extra twist. And sometimes, it really can’t be done.

You’re right about the remarkable degree to which the menus in a database can be customized in Panorama. You know me to be a long time user of custom menus. Currently there are so many ways to customize menus that it’s hard to know which is the best for the situation. Kudos there!

After spending several hours on the menus (I am persistent) I wasn’t sure if I had gotten as far as possible or not. I referred to the documentation on standardfilemenu( extensively, and frankly I struggled with it a bit. The [newDocument:] example to remove an item appears to be obsolete; probably due to Apple’s changes that you’ve noted. Then I found other clues on how to eliminate menu items in this thread. That brought me closer to my goal.

When I still came up short from where I wanted to be I choose to post here in case there was something I was missing; not to complain by any means. Now I understand that I’ve reached the limit of menu customization via the arrayhack(.

Probably I’ll build a few replacement menus myself with menuitem( and .CustomMenu, while accepting others trimmed to the closest point possible to where I’d like them to be.

Thanks for the thorough explanation. I learned from it and trust that it will serve others too - especially if they use the Search. :mag:

Actually I think this code will still work, even though these menus have changed quite a bit. I mentioned that the menu system is designed to be flexible to adapt to Apple changes, but it is also designed to be flexible to adapt to changes in Panorama itself. This example shows that. A few years ago the New Database item was moved from the main File menu into a File>New submenu. In spite of this rather major change, I believe that the examples shown on the standardfilemenu( help page will still work (caveat - I did not test them today), but you’ll see the effect of the changes in the File>New submenu instead of in the main File menu.

I wouldn’t feel bad about that. It’s not straightforward because rather than creating the menu arrangement from scratch, you need to puzzle out how to modify the existing structure to suit your needs, with an eye toward doing so in a way that will be as future-proof as possible. Of course if you aren’t concerned whether your menus work in future versions of macOS and/or Panorama then you can build the menus from scratch.

For what it’s worth, you are using the same menu building techniques that I do. There’s no “secret” menu interface available to ProVUE but not to regular users. In fact, even the “standard” Panorama menus are built using these same functions. You might find it useful to look at the InitializeMenus code in some of the databases that are built into Panorama, for example the View Organizer, Formula Workshop, Panorama Help, etc. (I have a convention of putting this code in a procedure called InitializeMenus, which is called from the .Initialize procedure. This makes it easier to modify the menus on the fly without having to close and re-open the database.)

Having said there is no difference – there is always an exception. The Panorama and Help menus are created by Apple and can’t be modified dynamically at all. There are obviously custom items placed in those menus by Panorama, but this is done using Xcode so these items cannot be changed without rebuilding Panorama from the source code. So you will not be able to modify these two menus at all, they are fixed.

Sorry I got a bit defensive there, my bad.

FYI, I never use .CustomMenu any more. Instead I put the code needed into the menu definition itself. If it’s a lot of code I’ll call a subroutine. I like doing it this way because then the entire menu definition is all in one place, instead of being split between the menu formula and the .CustomMenu procedure. However, this is simply a preference on my part, there’s no disadvantage to using the .CustomMenu procedure if that is your preference.

I always try to write for the benefit of future forum searchers as well as the current post. If you’re reading this in 2024, bonjour!

Personal preference rules! When building my own I use .InitializeMenus called from .Initialize (wonder where I picked that up). Right behind it is my .CustomMenu procedure so I have the menu creation nice and concise with all their definitions in an equally orderly page.