Hi,
Imagine if you will a grid of 40 or so unbound buttons on a form, all of which are initially hidden, and a database structured with two levels of category with products that are tied to the outer category in a loose way.
When the form loads it displays on the top row of buttons as many of the categories as it can. Additional Next and Back buttons would be used to move between pages of these categories. Initially 0 - 7 would be loaded, then 8 - 15, etc. The categories could have a view order int column to load the most common first.
When clicking a top level category button, all sub categories will be loaded into as many of the lower buttons as needed and in turn when clicking one of those sub categories all products would be loaded.
Workflow would be:
Meal Deals -> Burgers -> Half Pounder, Chips and Drink -> Child Form appears to edit notes for kitchen, set qty, etc -> Add to order. Back.
Child form calls basket function in module. Module calls public function in form to refresh itself to update order total, qty, etc.
This is similar in theory to the solution I implemented.
Another way would be a column of buttons down one side of the form with a listview on the right. You would use a similar tier loading mechanism to the above but the same buttons would be reused each time and the products to order loaded into the listview.
Workflow is similar execept you click an item in the listview to load the child form. The benefit of this version is you can stuff hidden data into the listview and push it to the child form saving a database call and alloows for richer UI design, too, like long descriptions and back office notes (out of stock, etc).
Each method decouples the UI design from the data, like a web page would, which in all honesty would be my preferred platform for this. Day by day you only need to add data to the database as new categories and products are added and the UI will cater for them.
Each method requires a state machine so the event handlers know which tier / page the form should be rendering.
The native Access 'switchboard' mechanism functions similarly to this, or it used to in older versions. I haven't used one in a long time but when I did I abused the heck out of it. If it still does maybe you could have it build one in a test DB and you can take a look at how it works under the hood and perhaps have a crack at modifying it.
But it won't be dynamic for example if new category is created than I have to make manual form and add buttons
Do you see how these methods remove this problem? The buttons are always there but hidden and repurposed on demand, and the adding and changing of products is done in the db.
This may seem complicated but I promise you, once it clicks you'll change the way you think about project design.
Gaz