How do you handle switchboards?

[CreganTur]

Like most everything else in Access, developing switchboards is a matter of personal choice.

I prefer to build my switchboards by hand, creating buttons that link to all of the forms and reports that a User would need to interact with, mainly because some of my applications have different switchboards depending on the status (Associate/Manager) of the user.

Some prefer to use the Switchboard Manager because of it's ease of use.

And other may have completely different ways of handling this issue.

So, how do you handle switchboards?

[OBP]

Me too. :beerchug:

[Mavyak]

Ditto. I don't even use bound forms. I do everything via ADO and create labels for users to click to navigate through the records. I like changing the color of the label on the mouseover event. I rarely trust the bells and whistles that are supposed to make life easier for the programmer. I'm quirky like that, though.

[CreganTur]

Ditto. I don't even use bound forms. I do everything via ADO and create labels for users to click to navigate through the records. I like changing the color of the label on the mouseover event. I rarely trust the bells and whistles that are supposed to make life easier for the programmer. I'm quirky like that, though.

Well early in my Access days- before I even knew what VBA was!- the book I was reading said that a Switchboard was "a form with buttons the user can click to navigate between all of the forms and reports they need."

I didn't even know about the switchboard manager at the time, so I started by making switchboards by hand. Seemed like the easiest way... still does, actually.

[geekgirlau]

I like to create them from scratch. This allows me to use images rather than buttons, and use mouse over events etc. - much more fun!

[DBinPhilly]

I've never used the Switchboard manager. It's far more convenient to create the menu you want by hand. Most of my latest menus have included tab pages for easier navigation and more logical work-flow. And it looks sexier to the user, too.

I don't use the mouse-over event to change object colors, either, unless there is a specific reason to do so. Otherwise it's an affectation that is all sizzle and no steak.

No offense to those that use it.

[Imdabaum]

For the most part, I'm with DBinPhilly. I love custom menus, even if I have to reference a website and 2 excel spreadsheets to do it in 2007.

I've never used an application that had a switchboard look for my own personal use, and find that the custom toolbar/ribbon feels more like a computer applications I'm familiar with.

On the other hand, I just inherited a database that was just 3 forms with several buttons on each that fired off macros. It is only for the devs that clean up the data so the DBWindow is visible. But I don't like to filter through the DBWindow for what I want, so I did use the switchboard manager so I could launch one of the 3 forms without switching categories etc.

If I 'NEED' one with more than 5 buttons, I'd make it from scratch. I generally discourage users from having me build them though.

[HiTechCoach]

I've never used the Switchboard manager. It's far more convenient to create the menu you want by hand.
If you have never used the Switchboard Manager, how can you honestly say for sure that "It's far more convenient to create the menu you want by hand"? In some cases I would have to disagree. You are definitelky not alone in this thinking. I am not sure why. :wot

How many people have actually looked at how the built-in Switchboard manager works and understand the power of the concept? I would have to say probably not many. I would also venture to say most of the people that say it is bad have really never used it. Or even understand why it is a great concept. They just are just “following the herd”

It may be that the Switchboard manger might be a to advance for new people to Access.

I am proud to say that I have used the built-in Switchboard Manage for many simple databases that have a limited number of forms and reports. It was fast, convenient and efficient. (cost my client less in billable time!)

I have developed my own version of the Switchboard manager that has expanded on the concept. One versions looks like a tabbed form, but really isn’t. Another uses the Windows Explorer Bar style. I can easily switch between types since the all work the same. This is still all based on the original concept of built-in Switchboard Manager.

What I normally see other using is a form, some with a tab control, that has lots of command buttons and other controls. Each command button has VBA code in an [Event Procedure]. Did you know that this type of form is very "heavy" on system resources. With 16-bit Windows this was very critical. Now with 32-bit Windows it is not as critical, but still should not be ignored. It still can cause issues.

I have a challenge:

Can anyone tell me what makes the built-in Switchboard Manger much “lighter” on computer resources compared to the above described normal menu?

[DBinPhilly]

Allow me to re-state the facts re: the switchboard manager.

I've tried it. I just never used the result.

Therefore, I never used the Switchboard Manager.

I always threw out the resultant Switchboard and wrote my own.

Hope you are more comfortable with that.

[OBP]

Boyd, can you have appearing and disappearing Controls, Fields and Combos plus multiple selections?

Being an Old Basic Programmer, where you had to Program EVERYTHING for yourself it is just more natural for me to use a form.

[HiTechCoach]

Boyd, can you have appearing and disappearing Controls, Fields and Combos plus multiple selections?

Being an Old Basic Programmer, where you had to Program EVERYTHING for yourself it is just more natural for me to use a form.

I an also an Old Basic Programmer and also a Cobol programmer. I marketed several MS Professional Basic apps pre Windows 3.1 and Access 2.0. In those day I found it critical to use a "light weight" menu just like the way the Switchboard manager is built in Access. When I saw this in Access it only seamed very logical to me. It was the way I have been doing it for years. IMHO, it is the most efficient way to program.

[hansup]

What I normally see other using is a form, some with a tab control, that has lots of command buttons and other controls. Each command button has VBA code in an [Event Procedure]. Did you know that this type of form is very "heavy" on system resources. With 16-bit Windows this was very critical. Now with 32-bit Windows it is not as critical, but still should not be ignored. It still can cause issues.
I have a challenge:
Can anyone tell me what makes the built-in Switchboard Manger much “lighter” on computer resources compared to the above described normal menu?
I can't.:( I would be interested to hear the details. Please tell us. Thanks.