Cramping many database application into one menu.

Hi, is it feasible to create a switchboard or main menu that contains all the following like:

a) Call logs monitoring menu buttons
- that opens a table that records call logs

b) machine leasing buttons
- that opens up menu list of all machine related matters

c) service order buttons
-records all sort of service orders.

d)stocks for internal use buttons
-records stocks that has been use for internal use.

Is there any standards that says one database menu is only for one kind of databases?

This is commonly referred to as a "nested menu" structure and is a very common way of drilling into multiple functions / depts within a larger database. It's also know as a switchboard or Navigation form.

You would probably want to have a top level menu with your 4 or 5 main areas of use, clicking on an item in that would either load a new menu form, or more efficiently simply load new buttons and target events.

There is a lot of discussion about the best way to achieve this - I would have a google for Access User Interface or UI for some design ideas.
Only you really know what would work best for your user

There's a free switchboard manager built by Microsoft which I believe exists in all versions of MS Access. However in later versions Microsoft Access it's a little bit difficult to find. Look at the video:- "FREE - Switchboard Builder from Microsoft" on my website:- http://www.niftyaccess.com/nifty-switchboard-builder/ you can see how to gain access to it and how to use it.

However you will probably find as I did that the Microsoft switchboard manager isn't the easiest thing to use! For this reason I created my own which is also demonstrated on this web-page "Nifty Switchboard Builder". It's available for a small fee.

By the way, I mention the Microsoft switchboard manager because it offers the nested functionality as described by Minty. You can create a page, and on that page each button will take you to another page, or to a Form, Report, Operation etc.

The switchboard builder is designed to handle 8 items on a page, however it is normal to have the last item as a "return to main menu button" in other words it serves no useful purpose except management of the menu system. Therefore from the are 8 options only 7 are useful on each screen. The number of options you can make available to the user would be 8 on the first screen then 7 on each one of those Eight, so that would be 7 X 8 = 56 and then if those 56 options give you access to a further sub-level of menus the total would be 56 X 7 = 392, if you went 4 levels deep 392 X 7 = 2744...

As Uncle G states you can easily use the switchboard system, and it doesn't take a lot of modification to make it work with a few more options.

I actually quite like them, and the simplicity of the fact that the options are all table based, rather than hard coded per se. As a concept I far prefer it to the newer Navigation forms.

Minty said:

As Uncle G states you can easily use the switchboard system, and it doesn't take a lot of modification to make it work with a few more options.

I actually quite like them, and the simplicity of the fact that the options are all table based, rather than hard coded per se. As a concept I far prefer it to the newer Navigation forms.

Click to expand...

I happened upon this thread again, and seeing Minty's comment about the Switchboard being "Table Based" reminded me of something worth mentioning, something that is very important about the original VBA controlled Microsoft Switchboard Builder.

It is constructed by a method of coding which I believe to be known as "Data Driven Programming" the number of items on a switchboard page, the text shown on the switchboard pages is defined in the table.

In other words there's no code to control the look of the switchboard pages, the code is designed to look in the table and from the information in the table it knows which options to put on to a particular menu page. Everything is "Data Driven"....

Unfortunately the latest version of the Switchboard Manager is based on macros, not VBA code. I personally think this is a mistake, however I do have an original VBA version if anybody wants to experiment with the data-driven concept. contact me and i will provide you with a copy...