The code behind each button click even on a form you build yourself sets the ControlSource of the Subform Control if you want to have the form work like the Access one. Otherwise, you can use a tab control and on each tab, put a subform control. In that version, you don't need code at all. Be careful using the tab control version because loading a form with dozen of subforms can be time consuming. That is why the Access version uses only a single subform control and loads the desired subform when you click a button. This makes the form less resource intensive but also less flexible since no subform can refer to any other subform since only one subform is ever loaded at one time.
I don't have a sample since personally, I use a Switchboard/Menu form that is controlled by a table. That way i don't have to modify a navigation form every time I want to add a new object. I just add it to the table and the option shows up in the list.
It is a matter of preference for how you want your interface to work and how much maintenance you are willing to do going forward. Using hardcoded buttons makes it more difficult to add new options because usually you don't want to just add the new option to the end of the row of existing buttons. Once you want to put the new option in some logical order, you have to rearrange all the buttons. With a Switchboard type menu, Items are numbered so you can just change their sequence by changing their number and you can also have a hierarchical menu so clicking on an option might open a form or might drill down to a more detailed list of options.
I attached a db with just the Switchboard form and Switchboard Items table. This is a modified version of the old Access Switchboard so it allows 12 items rather than 8 but that means that you can't use the wizard to update the Switchboard Items table for any item higher than the number 8. None of the form's buttons will work because none of the items they reference are included. To make this work for you, you would need to replace the items (except for the exit) in the table to reference your own forms and reports.
By examining the code, in the HandleButtonClick procedure, you can identify the values used in the Command field which specify what the button is supposed to do, i.e. open a form, run a macro, open a different switchboard, etc. The Argument field is the name of the object you want to "open" or execute.
The constant named conNumButtons is defined in the FillOptions sub. It is set as 12. The original version was 8. You can increase the number to whatever you want but you will need to modify the form to add additional controls. So, if you want the menu to show 16 items, change the constant to 16 and add four more buttons/captions with the appropriate values.