Custom menu isn't saved when database is closed

Panorama X
1

I’ve tried the following simple creation of a custom menu"

filemenubar "all",
    menu("Goodies") +
        menuitem("PrintProc")
save

The menu is created but when I close and re-open the database, it’s gone. What am I missing?

2

If that’s the whole procedure, you’re creating a temporary menubar. If you want it there on every launch, you should have an .Initialize procedure create it or call it. I’ve found it handy to have a procedure to restore Panorama’s menus too; sometimes hiding it for my own access but where other users won’t use it.

Hmmm, .Initialize isn’t under Help anywhere that I can find aside from passing references found in a Full Text Search.

3

None of the dot … procedures are documented - this is a big hole in the Help wizard but Jim will have it on his list.

4

If that’s true, it’s a huge limitation. I’m trying to build an application that will put a custom menu in one or more selected databases and building it into a pre-existing .Init procedure strikes me as a very clumsy way to do the job - not Panorama X style at all.

5

I’ve been using MenuBars in one form or another for years and have always used Initialize to load them. It’s a carryover from Panorama 6, maybe going back to 5 or earlier, but greatly enhanced now.

You may have your reasons, but if the file Initializes with the menus in place, how is that any different than if they’re somehow attached to the windows in the first place? The end user never sees the difference,

6

In this forum I’ve been excoriated repeatedly for any deviation from Panorama 6 to Panorama X. But, of course, the same thing happens when I do maintain compatibility (and in spite of what many think, huge effort was made into making Panorama X as compatible as possible with earlier versions).

In this case, setting up custom menus with the .Initialize procedure goes back to at least Panorama 4, nearly 20 years ago. (Maybe even Panorama 3? I don’t have a Panorama 3 Handbook handy at the moment). I tend to create a procedure named .InitializeMenus, and then call that from .Initialize. That makes it easy to modify the menus without having to rerun the entire .Initialize procedure.

Even if I was starting from scratch, I think I would do it the same way. Michael, with what you are proposing it would be very easy to create a database with permanently messed up menus. With the current system, you can always open the database without running .Initialize and you’ll get the stock menus back. Also, if the menus were saved permanently as you propose it would be very easy to lose the source for the menus, making them impossible to modify.

If there was some sort of full GUI interface for setting up custom menus, that would be a different situation. Maybe that would be more of what you think of “Panorama X Style”. But there isn’t – custom menus are set up with code, and I think it is perfectly reasonable, good actually, that that code needs to run when the database opens.

7

I do hope my comment didn’t come across as excoriating - I’m sure you know that it wasn’t intended that way. I was more surprised than anything else because I had always thought of custom menus as being semi-permanent in the same way that custom stat/funcs are. There is no mention of using the .Initialize procedure in any of the documentation for filemenubar, menu(, menuitem( or submenu(. I watched all two hours of the training video and my recollection (which could be wrong) is that placing the code in the .Initialize procedure was presented more as an option than as a requirement for an on-going menu. Maybe the pending Custom Menus entry in the Help wizard will make that point.

And I always have my Panorama 3 Handbook Supplement at hand - it is still useful :slight_smile: