Access On New Computer

[KitaYama]

If somebody wanted to enter a sales order they didn't need to be looking at the product and sales unit management area, so there was one menu tab for sales orders, and another for table maintenance, another for customer and customer branch maintenance, and so on.

You can do the same by adding tabs, and adding necessary controls in each tab.
Or adding several combo boxes for each on a single tab. Isn't working with a combo box easier than going to a menu and its submenus?
Or add a tab and use button group.

Note: It's just my side of how I see it. You may be more comfortable with menu. I don't argue which one is better. I just say think about new possibilities that a ribbon adds to your application.

 

[gemma-the-husky]

@KitaYama
I think that's just semantics. A navigation system of any sort is equivalent to a menu, and a large system just cannot display every option at the same time, so you need a way to drill down through the options.

If you add combo boxes you need to work out how and where to display and fill the combo boxes.

With a data aware menu system, all you need is to populate a menu page with the options you want to offer and the rest is automatic. No additional programming is necessary.

You can enhance the A2003 menu system to take into account a users group membership and thereby determine whether certain menu options are displayed, not displayed, displayed but jnactive or even displayed but read-only.

I'm sure you can do all this with ribbons as well, but the ribbons just take up too much screen real estate in my opinion.

Perhaps I'm a luddite and there is a slicker way.

 

[DickyP]

As I said, I don't remember the menu and how it worked.
Can you show some images of a menu with checkboxes, textboxes or toggle buttons?
I'd like to see a floating menu as well if possible.

thanks.

Next time I log on to my Laptop I print off some images. The floating menu will come first as I'll have to hunt for more complicated menus on my old BU hdds, since I seldom needed them.

What I didn't cover in my post was bit further down yours. Your description of multi level security is nothing to do with ribbons versus menus - as it used to be built in albeit not in 2003, and needed long re-inventing before ribbons.

And your language change on the fly would be easily implement on menus - the logic would be no different to using on ribbons. Check language at start-up and apply menus, sub-menus as appropriate. Here again the subject matter is not really a menu/ribbon comparison.

 

[DickyP]

I'd like to see a floating menu as well if possible.

thanks.

As promised.

Next time I log on to my Laptop I print off some images. The floating menu will come first

In reality all menus are floating - you just dock them where you want or drag into the main area.

 

[KitaYama]

As promised.

Next time I log on to my Laptop I print off some images. The floating menu will come first

View attachment 115311View attachment 115312

In reality all menus are floating - you just dock them where you want or drag into the main area.

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

Menus are the one at the top of the application.

 

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

 

[Pat Hartman]

The purpose of ribbon is not to work like menus. The purpose is to create something that can interact with the user and application.

The Ribbon is used to control the Access interface. If MS had intended the Ribbon to be used to create the application interface for the user, they would have given us options to hide options the users should not use as well as a tool to use to build the interface. Same for the right-click menus. According to the Access development team, their intention was for us to use the Navigation pain to replace the Switchboard, not the ribbon. The ribbon also takes up too much vertical space if you are not using it as an application menu. Due to its graphic capabilities, you can use it as an application interface but only if your interface is in tabbed view. Otherwise, it looks awkward. And WYSIWYG doesn't work properly in design view when you have to expand/contract the ribbon to give you more working space. And finally, I don't want to do development in tab view. I always want to be able to see multiple objects at once. So, because it is such a PITA to switch views, I don't create apps with tab views.

Just because I don't like the ribbon and I despise the Navigation pain(sic) doesn't mean I don't think Access is the best thing since sliced bread

 

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

 

[Pat Hartman]

You can right click and select shrink.

But WYSIWYG (what you see is what you get) doesn't adjust the other objects correctly. It either leaves the objects covered by the ribbon or it leaves them in awkward spots

If you are not using tab view, you are probably maximizing your forms to fill the empty space. Maximized forms can interfere with reports and popups so I don't use them either.

I don't "like" the ribbon but it is functional. I just have no interest in using it as the menu for an application. I dislike the Nav Pane immensely. It feels like the initial designers never worked with it in a database with more than a few objects or they would have fixed many of the annoyances. Not to mention going from 1 click to change the sort to a minimum of 6, simply is not an improvement in my world. It has been a long time since we lost the Database Window and probably many of the people reading this don't have a clue what I'm talking about. To them, 6 clicks to change the sort order is all they've ever known.

 

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

 

[Pat Hartman]

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

I've posted two sample databases with various options on how to change the look of the switchboard and even one completely custom version. One of the databases includes simple security that is implemented using the switchboard and the other has no security.

If you really like graphics, the custom switchboard allows you to make your own button images. I don't have a tool to create tiny pictures and so I just copied a few that were already made.

P

Thread 'Switchboard with simple security'

Mar 7, 2022

This is a custom switchboard. It expands on the Switchboard Items table to add four additional columns to define view/edit/add/delete security levels for switchboard items and forms/reports referenced by them. It includes tables to manage users and also to assign them security levels. The user maintenance form and the menu maintenance form use the security to determine whether to allow the requested action. The switchboard form also uses the view security to determine whether a user even sees a switchboard item. The database opens to a logon form. It gives you three different logins...

• Pat Hartman
• Replies: 9
• Forum: Sample Databases

• 

P

Thread 'Replacement Switchboard'

Feb 13, 2022

This Switchboard form is based on the last VBA version which I think was A2k. I expanded it to allow for 12 items rather than 8 and you can easily change it to do more. I've included directions. This updated version has two switchboards. One more traditional and the other is big buttons.

THERE IS A NEWER VERSION DOWN AT THE END. IT HAS A MORE VERSIONS OF THE SWITCHBOARD

• Pat Hartman
• Replies: 11
• Forum: Sample Databases

• 

 

[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

 

[Pat Hartman]

Haven't used one in years as they are far too restrictive and. limited

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.

 

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