Switchboard as subform

[ozzi]

Hi All,
i have been wrestling with this for a while, so i hope somebody can suggest something.
I have several forms for data display and data entry. Each of these forms requires several command buttons with different functions on each form. for the sake of consistant appearance, i would like something like a switchboard as a subform. populating the subform switchboard table manually is a big drag, so i am hoping that there is a way to create the switchboard table with the switchboard manager.

TIA ozzi

 

[Roku]

G'day Cobber from a Pommy

Make a table of all possible commands for all subforms. In each row, include fields to identify the form (form name, perhaps), the specific command to be included as a number (relative to the form), the caption to be shown on that button and the required command action.

Design your subform based the table. In the subform, define the maximum number of command buttons you need. Name these in a logical way, such as cmd01, cmd02 etc. Set every button Visible property to False. Add anything else you need for your requirements. The form does not need to be bound to a data source.

In the Form_Open event (for the subform), retrieve the subset of records you need from the table, filtering by the identity as defined in the table. Iterate all command buttons from that query, matching the numeric reference in the table to the command suffix ("01", "02" etc). Where the query matches, set the button Visible property to true and its caption to the table value. You could use the button's Tag property to hold the action as defined in the table.

You could put the logic for each command in the parent form, the subform or a separate module - the choice is determined by complexity and maintenance factors.

This approach will give you flexibility, with just one form to maintain.

If you need some examples, let me know. I threw the Switchboard away many years ago and wrote my own, which gives me much better control.

 

[ozzi]

G'Day Roku

G'day Cobber from a Pommy

Make a table of all possible commands for all subforms. In each row, include fields to identify the form (form name, perhaps), the specific command to be included as a number (relative to the form), the caption to be shown on that button and the required command action.

This is the bit that is the Drag. With 10 or more forms, with upto 12 command buttons each, entering this data into the table manually is not fun. The switchboard manager UI makes this task easier. Is there any way i can use it to enter the data?

Design your subform based the table. In the subform, define the maximum number of command buttons you need. Name these in a logical way, such as cmd01, cmd02 etc. Set every button Visible property to False. Add anything else you need for your requirements.

CHECK. Copy switchboard form and format to my needs. I assume you mean the forms record source is the table created above, but

The form does not need to be bound to a data source.

what do you mean??

In the Form_Open event (for the subform), retrieve the subset of records you need from the table, filtering by the identity as defined in the table. Iterate all command buttons from that query, matching the numeric reference in the table to the command suffix ("01", "02" etc). Where the query matches, set the button Visible property to true and its caption to the table value. You could use the button's Tag property to hold the action as defined in the table.

You could put the logic for each command in the parent form, the subform or a separate module - the choice is determined by complexity and maintenance factors.

This approach will give you flexibility, with just one form to maintain..

Good point, but as a module it can be accessed from any (switchboard) form and is portable.

If you need some examples, let me know. I threw the Switchboard away many years ago and wrote my own, which gives me much better control.

Thanx, reading code and trying to understand it is something i would enjoy.
A small sample would be appreciated.

I haven't been on this forum long and i am getting the destinct impression that most here don't like the access switchboard.
Could you enlighten me as to why?

Living in regional Queensland there are not many people that even know what access is, so most of what i know is from books and deconstructing someone elses code. I am not familiar with a lot of things you guys might think is common knowledge. Again please enlighten me.

Thanx ozzi.

 

[Roku]

Regional QLD is a big area! It's a long time since I was there, but I was mainly working in the Brisbane area.

I'll put an example together for you to illustrate my techniques, which will take me a day or so. I'll address your specific points therein.

I don't know about others, but the reason I ditched the switchboard was its lack of flexibility. Mine allows more content, with user-hooks to add customised code for specific tasks. I also use it to save state between sessions. I originally wrote this in VBA, but I'm currently rewriting it in VB.NET, to make it a stand-alone application to construct menu table and associated form, plus enable maintenance on a menu table in any Access DB.

 

[ozzi]

A big "Thank You" Roku, There is no great rush as i will still be trying out your suggestions.

thanx ozzi

 

[Roku]

As promised, I have constructed an example of using a common menu as a subform to multiple forms.

I originally tried to make the menu work in stand-alone mode as well as in embedded mode, but this proved more complex than I had anticipated. I got it working eventually, but I reverted to the more simple version for this example.

The principle here is that a single menu table is used for multiple forms (limited to 255). Each form contains a subform (sfShared) which contains the menu form (fShared). There is a main menu form (fMenu) which opens when you open the DB - this is used to open other forms which each have their own copy of the subform. In every case, the parent form name is used to select the relevant items from the menu.

The menu table contains control records, which are used for the internal workings. I have set two examples to show a static item (the main menu title) and a variable item (the last run date). These are identified with Form=0 in the table.

The menu itself is constructed in a Tab control, which has five tabs. Each tab contains six command buttons with associated labels. At run-time, only one tab is visible, with navigation between them achieved by the menu function (you'll see examples of this in the pages used).

I have allowed for user-code to be added in the module mMenus. You will see conditional compilation there, because I have two different ways to achieve the same result - it's a matter of personal preference.

I'm not going to explain the workings here - I have used comments to guide you through the process. If you encounter something which needs explanation, post your question here.

There is a query which might help you to see the menu table contents better. It has two parameters, [Form] and [Page].

There are some loose ends left for you to trip over - see if you can work out how the 'Close Form' menu action might work. Nothing happens in this version.

There are three 'hard' dependencies (that I remember). One is the need to run the fShared form within a subform control; next, is the naming convention for menu controls (commands and labels) in the menu pages (cmdppii and lblppii, where pp corresponds to the menu table mtPage field and ii to the mtItem field); the third is that each command (ctlppii) must be associated with its label (lblppii).

I have not included much error-checking, so you can expect failures - these will generally be data-dependent (i.e. the menu table content is unexpected). I would use a menu-builder form to manage the content to ensure valid relationships, but that's another project.

As this is a public post, the code is freely available to anyone who wants to use it. I ask merely that you let me know if you can improve the functionality and/or logic. Please acknowledge the source if you use or adapt the method.

Have fun!

 

[ozzi]

Thaaannk You Roku,

You Rock, Dude.

my own attempts have/are still not leading anywhere, so I will be going over this with a fine tooth comb to see what i can learn.

Thanx ozzi