Hi Hilmar,

Thank you for your response. We currently have over 300 entries in our menu system. This does not include reports. We would like to keep the menu system as is (if for nothing else, so we don't have a revolt on our hands from our customers)<g>

We have many modules, too many to make a pageframe for each.

I think the idea of a table to hold the entries of the menu is great. I'm just not sure how to dynamically build this menu from the table. I would assume we could do it after the employee logs in...so that we can include or exclude menu options based on security.

Thanks again,

Paul

>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.
>