Access On New Computer

[Isaac]

Tab control? Tab control belongs to forms, I think.
I had a feeling the discussion was about menu.
Did menu (at the top of the application) have tab controls?
(sorry for the stupid question. I can't remember.)

you wouldn't allow the ribbon on a user-deployed db, would you?

 

[KitaYama]

you wouldn't allow the ribbon on a user-deployed db, would you?

Why not? Of course I do.
Is it wrong to have a ribbon in a db?

 

[Isaac]

Why not? Of course I do.
Is it wrong to have a ribbon in a db?

it's totally up to you. i wouldn't, i'd disable all that and have the user use only the menus I'd designed.

 

[KitaYama]

it's totally up to you. i wouldn't, i'd disable all that and have the user use only the menus I'd designed.

Oh, I see your point now. Seems that you've not worked with ribbons yet.
When you creat a ribbon, you can add a from scratch keyword to the first line of xml. If you add it, the default ribbon will be destroyed and you add your own tabs and controls. None of Access default tabs will be shown. You have only your tabs and controls.

I'm on my phone. I'll post an image when I'm back to my PC to see how my ribbons are.

 

[DickyP]

Thanks. But aren't they toolbars and not menu?

Menus are the one at the top of the application.

Sorry - yet again you don't understand the menu system in pre-ribbon MS Office. - the menus at the top (or side, or bottom, or floating according to where you put it) are just another toolbar - called Main, and the applications regard all of them as toolbars. And the other toolbars have menus off them, as necessary. You can easily hide the main toolbar if you don't want users playing and replace it with a document specific menu when a document loads.

The other thing nobody else has mentioned - all you need to create, edit or delete toolbars/menus was/is particular application itself. No need to faff around with XML and other tools, just use the object model and manipulate them in VBA if they needed added complexity, or build them using the inbuilt tools.

If you get a chance you should look at the Object model for menus to see just how powerful it is/was, especially in Word and Excel.

 

[KitaYama]

@Pat Hartman I’m sorry, but my English is not good enough to understand your points. I will wait for m son to see if he can translate it to something that I can understand.
For now, the only thing that I think I can reply ;

The ribbon also takes up too much vertical space

You can right click and select shrink. It will hide the ribbon and only shows the name of the tabs. Clicking each tab, shows the menu and you can select anything you want.

Due to its graphic capabilities, you can use it as an application interface but only if your interface is in tabbed view

I really am interested in understanding what you exactly mean by this. I’ve never used tabbed view, and I’ve always used ribbon as application interface. Would you pleas expand on what you meant by this? Thanks.

 

[Isaac]

Oh, I see your point now. Seems that you've not worked with ribbons yet.
When you creat a ribbon, you can add a from scratch keyword to the first line of xml. If you add it, the default ribbon will be destroyed and you add your own tabs and controls. None of Access default tabs will be shown. You have only your tabs and controls.

I'm on my phone. I'll post an image when I'm back to my PC to see how my ribbons are.

I've certainly not created one yet, I just disable the ribbon and make custom menu's.
I think that's quite common for access dev's, but if you have luck enabling the ribbon safely and customizing it, great

 

[gemma-the-husky]

What I found was that the A2003 menu (and the A97 menu) was/is a dream to use. It uses a very simple process to successively show user designed pages of menus.

You design numbered pages, so page 1 may have say 10 options*

The default was 7, I think, but I ended up having 25 options, 3 columns of 8 items, with a final option 25 to return to the previous menu page. (I might have done 31 items, rather than 25). 7 options is just too few. It's a bit fiddly to set up, but you only have to set up the form once.

I'm sure @Pat Hartman says she does something very similar.

The entries you design for page 1 may open forms, open reports, run queries, or jump to a different menu page. In fact it's easy enough to add code to do any other action you desire. I only ever opened forms from my menus. Very occasionally I did something else. I had an all purpose report manager form to deal with reports. The only catch is that every page needs to have an option 1. I couldn't work out how to get it to comply if there wasn't an option 1, so it was easiest to always have one.

I never understood the changes that came in from A2007 onwards (maybe it didn't change till after A2007). So all I ever did was pull in my A2003 switchboard form, and switchboard items table into later databases, and manually edit the table.

Maybe hierarchical menus are a bit old fashioned, but I just think they work well for many business applications.

I also added an A2003 menu bar which duplicated many of the switchboard options. I tried, but struggled to achieve this with the ribbon. I didn't remove much of the existing menu bar options. I think it's useful for users to have those features at times.

 

[DickyP]

The whole Switchboard discussion is a but like building the a better musket in the 21st century ie pointless. Haven't used one in years as they are far too restrictive and. limited

 

[DickyP]

Your choice but why? because they are data driven and can be changed by changing a row in a table? The point of a menu is to provide an overview of the structure of an application. It should be able to allow the user to drill into the part of the app he wants to work by using only a couple of clicks and it shouldn't take hours to modify if you want to rearrange things. Switchboards can be as pretty as you want them to be. Add all the graphics you want.

Switchboards are appropriate and easy to implement for the majority of the types of data driven applications that we create with Access. But, smaller apps that have little to no expansion potential can use hard coded "pretty" forms without a lot of work. It is the rework caused by having to reorganize a menu that is hard coded after it's built that has led me to stick with data driven forms. My clients are paying for functionality and rapid development rather than fancy, hard-coded, graphic layouts - unless the app's purpose is to display graphics.

Didn't say they were useless merely that you confine yourself the a fixed number of buttons. The task they do isn't pointless just that there are easier and more flexible ways of doing it (and they are data driven too).

 

[KitaYama]

I don't "like" the ribbon but it is functional.

That's the whole point I was trying to make. As far as you see them functional, it says you know how they work. Anything else goes to personal preferences.

 

[KitaYama]

Sorry - yet again you don't understand the menu system in pre-ribbon MS Office. - the menus at the top (or side, or bottom, or floating according to where you put it) are just another toolbar - called Main, and the applications regard all of them as toolbars. And the other toolbars have menus off them, as necessary.

I'm sorry too that I don't understand it.
To best of my knowledge, from the OS stand point, a menu is different with toolbar. I don't care what and how, you or traditional Office call them.
According to Microsoft CoPilot:

Toolbar​

• Purpose: Provides quick access to frequently used commands.
• Appearance: Consists of buttons, icons, or small graphics representing commands.
• Location: Typically found at the top of an application window, below the menu bar, can be used floated around the screen.
• Functionality: Executes commands immediately when clicked, like saving a file or printing a document.

Menu Bar​

• Purpose: Lists available menus, each containing related commands.
• Appearance: Text-based, with each menu name (like "File," "Edit," "View") leading to a dropdown list of options, fixed position.
• Location: Usually positioned at the very top of an application window.
• Functionality: Requires users to navigate through dropdown menus to find and execute commands.

Since we can't agree on this simple point, then I think any further discussion is just useless. For the sake of both of us and others who participated in this thread, it's better to stop insisting on our views.
Let's agree to disagree on this case. As I said in my previous post, it all goes to personal preferences.
I appreciate your patience with my posts. It was a great discussion and thanks for your time.

 

[DickyP]

I'm sorry too that I don't understand it.
To best of my knowledge, from the OS stand point, a menu is different with toolbar. I don't care what and how, you or traditional Office call them.
According to Microsoft CoPilot:

Toolbar​

• Purpose: Provides quick access to frequently used commands.
• Appearance: Consists of buttons, icons, or small graphics representing commands.
• Location: Typically found at the top of an application window, below the menu bar, can be used floated around the screen.
• Functionality: Executes commands immediately when clicked, like saving a file or printing a document.

Menu Bar​

• Purpose: Lists available menus, each containing related commands.
• Appearance: Text-based, with each menu name (like "File," "Edit," "View") leading to a dropdown list of options, fixed position.
• Location: Usually positioned at the very top of an application window.
• Functionality: Requires users to navigate through dropdown menus to find and execute commands.

Since we can't agree on this simple point, then I think any further discussion is just useless. For the sake of both of us and others who participated in this thread, it's better to stop insisting on our views.
Let's agree to disagree on this case. As I said in my previous post, it all goes to personal preferences.
I appreciate your patience with my posts. It was a great discussion and thanks for your time.

Cheers - it was a fun chat and just to confuse thing Microsoft called them all Command Bars!