Revert to std menus/toolbars during runtime

  • Thread starter Thread starter Dymondjack
  • Start date Start date
D

Dymondjack

Hi all, thanks in advance for any pointers.

I was curious if anyone knows of a way to programmatically restore Access
default menus and toolbars (same as holding 'shift' on startup).

I'm working on a project that will have about 5 users on different
computers, and have the startup options set so noone can get to the
code/tables all that easily (luckily, none of the users are powerusers of
access).

Ideally, if there is a major unhandled error that comes up on a user's
interface, I could have a semi-hidden & password protected function that
would restore the standard properties for the active application, in which
case I would be able to debug it at my leisure.

Not too big of a deal either way (I'm really hoping not to need it), but it
would be nice to include.

Thanks!
-jack
 
Thanks Mike. Not exactly what I had in mind, but I can certainly use this
password feature to my advantage. I had not been aware of it until now.

Thanks for the tip!
 
If you distribute an mde to your users, any un-handled error will not cause
a problem and the application will continue to run, and you'll also not have
any loss of local or global variables when this occurs.

As for restoring the menus and that during the debugging process, I can
really think of a way to get around this problem, but on the other hand

You most certainly can, and should hide all of the ms-access interface. The
options to complete hide and keep people out of the ms-access interface can
easily be done using the tools->start-up options. Using those options allows
you to complete hide the ms-access interface (tool bars, database window
etc).

Also, using these options means you do not have to bother setting up
security.

Try downloading and running the 3rd example at my following web site that
shows a hidden ms-access interface, and NO CODE is required to do
this....but just some settings in the start-up.

Check out:

http://www.members.shaw.ca/AlbertKallal/msaccess/DownLoad.htm

After you try the application, you can exit, and then re-load the
application, but hold down the shift key to by-pass the start-up options. If
want, you can even disable the shift key by pass. I have a sample mdb file
that will let you "set" the shift key bypass on any application you want.

You can get this at:

http://www.members.shaw.ca/AlbertKallal/msaccess/msaccess.html

Of course, during development, you will hold down the shift key so your
startup settings don't run. You then develop for awhile, and then to test in
"user" mode, you exit..and then re-enter the application without the shift
key bypassed. You will likely do this dance all day long as you run/test as
user mode, and then flip back in to developer mode (shift key used..so you
don't get the main custom menu). So, you can't develop, or really modify
things when you run your application with the startup settings...so you must
shift-by-pass them when you want to work.

And, in fact, I use alt-f4 to exit the application...the mdb file should
still be highlighted in the windows explore..so, then you hit enter key
(and, hold down shift key if you need be). This key stroke sequence and
exiting and re-entering the application will occur CONSTANTLY all day long
when you are developing.

When you finally have things just right...you create the mde
you plan to distribute...
 
Thank you all for your input. I believe I have come to a solution based on
all it.

Unfortunately, circumstances require me to implement this project before I
have had time to test the app on more than my home or my work computer, and I
am hesitant as of yet to deploy a .mde copy.

Fortunately, this needs to be immediately available to only one person for
the next few weeks, with whom I am in close contact with on a daily basis.
So, while I would still rather not use an mde (I want to be able to closely
moniter the entire application for a while yet), I can do the following:

Keep user interface clean:
- Set all startup properties (remove/replace msaccess interface)

Keep user from code and maintain access for me, if I need it:
- Set Shift Bypass Password (neat trick, I like this one a lot)

Access Code during a run-time error to debug with a real-time application
environment:
-Application.CommandBars("Menu Bar").Visible = True

While I do not expect any unhandled errors, this will allow me to handle
anything too out of the ordinary without having to try and recreate it.

Over the two to three weeks the project will undergo extensive testing in
this user's environment, after which a final mde will be created and
distributed to all users.

Mission accompished! Thanks to all for the ideas, the psuedo-beta version
is teasted and ready to go tomorrow.

Greatly appreciated,
-jack

p.s. - for anyone interested, here's an api I used in my global error
handler. The function sits directly after the msgbox display, checks to see
if the shift key is pressed (Hold Shift key when clicking 'OK' on error
msgbox), and is followed by a conditional that will prompt the user for a
password to unlock the native access interface.



Public Delcare Function GetAsyncKeyState _
Lib "user32" ( _
ByVal vKey As Long _
) As Integer


Public Function fGetShiftCtlAltState() As Integer
Dim iKeys As Integer

Const pcSHIFT As Long = &H10
Const pcCTL As Long = &H11
Const pcALT As Long = &H12

If GetAsyncKeyState(pcSHIFT) <> 0 Then iKeys = iKeys + 1
If GetAsyncKeyState(pcCTL) <> 0 Then iKeys = iKeys + 2
If GetAsyncKeyState(pcALT) <> 0 Then iKeys = iKeys + 4

fGetShiftCtlAltState = iKeys
End Function
 
Back
Top