SwitchBoard

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

There probably is a tutorial, and this may be sidestepping your question, but
a switchboard is just a form with a VBA module and a table of items for the
form. To find out how it works, use the wizard, then open the newly-created
switchboard in design view.

I don't use switchboards myself, but a much simpler approach (and maybe a
little less professional looking by some standards) by just creating a form
with buttons on it. The Click event of each button opens a subform related to
the caption of the button (i.e. Sales Menu, Contacts Menu, etc.)
 
Hi Brian,
I don't use switchboards myself, but a much simpler approach (and maybe
a little less professional looking by some standards) by just creating a form
with buttons on it.
Click to expand...

This is also a switchboard! Just because you avoided using the sucky
switchboard manager wizard, you have still created what is commonly referred
to as a switchboard. In fact, I would argue that your form, which likely
involves an unbound form, is a lot more professional looking than what the
switchboard manager creates.
The Click event of each button opens a subform related to
the caption of the button (i.e. Sales Menu, Contacts Menu, etc.)
Click to expand...

Are you sure the click event opens a subform? It sounds to me like you are
opening up the required forms, not subforms.

Tom
______________________________________

:

There probably is a tutorial, and this may be sidestepping your question, but
a switchboard is just a form with a VBA module and a table of items for the
form. To find out how it works, use the wizard, then open the newly-created
switchboard in design view.

I don't use switchboards myself, but a much simpler approach (and maybe a
little less professional looking by some standards) by just creating a form
with buttons on it. The Click event of each button opens a subform related to
the caption of the button (i.e. Sales Menu, Contacts Menu, etc.)
_____________________________________

:

Hi,
Is there a tutorial or step by step that helps me make a switchboard menu
manualy.
I like to design my own instead of using the switchboard manager in access.

Khalil
 
Hi,
Is there a tutorial or step by step that helps me make a switchboard menu
manualy.
I like to design my own instead of using the switchboard manager in access.

Khalil
 
How can we make sure that only the switchboard(and related forms) will
be available to the user, so that she will not mess up with the database?
 
Use Tools > Startup... to specify your switchboard as the startup form.
(Alternatively, you can use a macro named Autoexec, and specify your startup
form there). Deselect "Display Database Window" and "Use Access Special
Keys". You may want to experiment with the other selections as well.

If you want, you can take it a step further by disabling the shift key.
Usually, holding down the shift key, while starting a database, will bypass
an Autoexec macro and the settings made under Tools > Startup... You can use
code to disable the shift key trick, although savvy users can always
re-enable it. Most user's don't even have a clue about holding down the shift
key, let alone how to disable or re-enable it. Post back if you want more
details on this.

Tom
______________________________________

:

How can we make sure that only the switchboard(and related forms) will
be available to the user, so that she will not mess up with the database?
 
Yep. I meant another form, not a subform. Good catch. I guess it was just
late. You are also correct about it being a switchboard. I meant to say I
don't use the switchboard wizard.

Yes, mine are just unbound forms that allows access to various parts of the
program. Various buttons are enabled/disabled based on user security levels.
 
I use a double-click of a hidden control on the startup form, combined with a
password dialog, to enable/disable the AllowBypassKey property. Am I correct
in assuming that one of those "very savvy" users could still enable this
property without being able to open the DB (like opening another db and using
VBA to set the property's value back to False)? At some point, an .mde starts
to look like the best option.
 
Brian,

This is what I want to do; to be able to make some buttons work ONLY
with a password.

I do not know if this is possible but??
 
You could do one of these two (and I'm sure there are many other ways):

1. Use an InputBox to have the user enter a password in the Click event.
Then check to see if the password matches your predefined password.

Button1_Click()
If InputBox("Enter password.") = "1234" Then
MsgBox "OK"
Else
MsgBox "Not OK"
End If
End Sub

This requires storing the password in VBA code. It would probably be better
to create a hidden passwords table (e.g. two fields: PasswordButton,
containing the names of the buttons where the password will be required &
Password, containing the password) and look up the password like this:

Button1_Click()
If InputBox("Enter password.") =
DLookup("[Password]","[Passwords]","[PasswordButton] = 'Button1'" Then
MsgBox "OK"
Else
MsgBox "Not OK"
End If
End Sub

2. You can enable/disable the buttons themselves based on who the user is.
This requires a table of users and a way to capture a user name and/or
password in a login form. I have the user type the user name, compare it to a
list of users in a table, then record (to a global variable) the user name.
Then, when I open the switchboard form, I DLookup the security level for the
user and put some code like this:

Form_Open()

Select Case UserLevel
Case is = 1
Button1.Enabled = True
Button2.Enabled = True
Case is = 2
Button1.Enabled = True
Button2.Enabled = False
End Sub
 
Hi Brian,
Am I correct in assuming that one of those "very savvy" users
could still enable this property...
Click to expand...

Yep. You need to implement Access "security" in order to secure the allow
bypass key setting. See the following article for more details:

Securing AllowBypassKey
http://www.mvps.org/access/general/gen0040.htm

However, Access security is not all that secure. There are free tools
available on the internet to crack the best Access security in a matter of
seconds if one has the workgroup information file (.mdw file) available.

At some point, an .mde starts to look like the best option.
Click to expand...

I always distribute in .mde format only for regular users. Your code stays
compiled, and there is a reduced chance of encountering MISSING reference
errors. However, the allow bypass property can be easily reset, even in .mde
files.

Tom
______________________________________

:

I use a double-click of a hidden control on the startup form, combined with a
password dialog, to enable/disable the AllowBypassKey property. Am I correct
in assuming that one of those "very savvy" users could still enable this
property without being able to open the DB (like opening another db and using
VBA to set the property's value back to False)? At some point, an .mde starts
to look like the best option.

______________________________________

:

Use Tools > Startup... to specify your switchboard as the startup form.
(Alternatively, you can use a macro named Autoexec, and specify your startup
form there). Deselect "Display Database Window" and "Use Access Special
Keys". You may want to experiment with the other selections as well.

If you want, you can take it a step further by disabling the shift key.
Usually, holding down the shift key, while starting a database, will bypass
an Autoexec macro and the settings made under Tools > Startup... You can use
code to disable the shift key trick, although savvy users can always
re-enable it. Most user's don't even have a clue about holding down the shift
key, let alone how to disable or re-enable it. Post back if you want more
details on this.

Tom
______________________________________

:

How can we make sure that only the switchboard(and related forms) will
be available to the user, so that she will not mess up with the database?
 
Back
Top