Well, for example, one frequent entry in the menu is an access to a specific form.

An alternative, which is much more flexible, and doesn't force you to redesign your menu every time you do changes, is to have a special form, which you access with "File | Open", which lists available forms.

On this form, in a ListBox or Grid, you can list available forms. This can vary, depending on user rights (this is part of the flexibility I mentioned). The contents of the "File | Open" form would be loaded from a table.

Now, when you add a form, all you need to do is add a record to the forms table.

You can also divide the forms into several categories, with a PageFrame, or with a ComboBox selector. For example, I use the categories "Data entry forms", "Reports", and "Processes".

Compared to putting each form into the main menu, you have several advantages, especially:

You will likely no longer encounter the "menu too big" error.

It is easy to add a form. You don't need to recompile the menu.

It is easy to disable - or simply not show - individual forms, depending on user rights.

HTH,

Hilmar.

>I can no longer add anymore entries to my menu. I now get "Program is too large" when compiling.
>
>I did some searching and saw where Sergey had responded to somebody that the solution would be to build the menu dynamically at runtime from a table.
>
>Would anybody have an example of how to do this? Is this the best and/or only solution to this problem?
>
>Thanks,
>Paul Acton

Difference in opinions hath cost many millions of lives: for instance, whether flesh be bread, or bread be flesh; whether whistling be a vice or a virtue; whether it be better to kiss a post, or throw it into the fire... (from Gulliver's Travels)