I have created some password routines to protect certain forms from access
without a password.
This allows me to create some security for apps that will be used on diff
machines for users that will not have to learn the whole access security
process
I don't think the users would have to learn much, if anything. Likely now,
these uses have to enter passwords for many things, and often just to logon
to windows. So, from a user point of view, there is really NOTHING that the
users have to learn. Fact is, you mentioned that you already have some
screens that prompt for passwords anyway. So, from a user point of view,
really nothing need be learned.
Ok, now that is fair. Learning security can be somewhat confusing and
difficult at first. However, the time you spend writing all that password
stuff for those forms could have been spent learning ms-access security.
And, once you learn ms-access security, then preventing users from using
certain reports and forms takes NO code. It is all done for you. Right now,
you are restricting some forms,but likely restricting some repots etc to run
also will be needed. You don't want to have to write code for all this
stuff, as then your application will become harder and harder to maintain as
you spend more time writing bits of code to manage security when you should
be working on adding new useful things to your application.
I would like to lockup my database by unchecking all of the options in the
tools/startup from.
Un-checking all the options is not needed here, but point well taken. The
best approach here is to ALWAYS give your users a mde. A mde file is a file
with all the source code and ability to design or modify forms removed. In
fact, if you loose the original mdb, then even YOU can't modify your
application at that point. Further, creating a mde is easy, (tools->database
utilities->create mde). The mde is thus your final "production" version of
the application that users get. So, it is standard fair for a developer to
distribute a mde, as they are smaller, run faster, can't become
un-compiled, and users can't modify them. Also, a mde can't have any code
compile errors either (so, it checks your work for you!).
I know i can create custom menus, toolbars and command bars and add a link
to the access startup from there, but have had some problems getting the
popup bar to only be available for only 1 form that is protected by my
password routines.
Actually, often I just make a super tiny menu bar with file->exit on it. It
takes less then one minute. Just specify this super SIMPLE menu bar for your
start up stuff, and that will hide all of the ms-access interface for you.
The one I created somehow became global and even after removing it from
all of the forms, access will still look for it on report and show it as
missing when you right click the report title bar. Then it pops up the
design option on a right click .
Perhaps, you might start a separate question on this issue. It would seem
that solving the above problem would be a good solution here.
Anyway here is my question. Is it possible to call the access
tools/startup form
Yes, the above question is possible, and it the above question makes sense.
with a procedure linked to a forms on load event and how.
HUH? Ok, now I am complete lost, and don't understand the above? What, or
why would you use a forms on-load event to open another form, or display the
startup stuff? Perhaps you mean you have a form, or some menu, and when you
select that option, or click on a button, then the built-in ms-access
startup option form appears. So, sure, you might build some "system setup"
form that lets you do things like manage your passwords, and do things like
launch the tools->startup options form, sure that sounds ok. However, doing
this on a forms on-load ?...I just complete lost here??? this makes no sense
at all??? (I obviously miss-understand what you want in this regards to the
on-load event).
Normally, during development, you simply hold down the shift key during
startup, and all those startup options are by-passed. No doubt, you spent
some good time setting those startup options....and finally got them exactly
the way you want. Once you set those options, then just leave them alone.
So, to work on your application, just hold down the shift key during
startup. Thus, during development and testing, , you "often" might want to
see how things work from a "user" point of view. You thus can whack alt-f4,
and exit the application. At this point you are back to the windows
explorer, and hopefully the icon that you used to launch the application is
still highlighted (it should be). You can then whack enter key. At this
point, you don't hold down the shift key, and now can test the application
in "user" mode. You then play, test, check things etc. Now, exit again
(alt-f4). Again, now just whack enter key, but hold down the shift key
during startup. So, often many times during the day when you are developing
an application, you will modify forms, test some code, and test some forms.
Also, because the startup options can effect the way some things work, then
obviously, you will try and test things with the startup options enabled
also (you really want to do this before your users try it!!).
So, thus, again, that alt-f4....exit...then "Enter" key sequence occurs VERY
fast. My point is as you develop, you will often want to test things with
all startup options, and how things will work/look to the end user. After
you play, then again..exit.....and the fast re-enter holding down the shift
key, and you are right back into developer mode with none of the startup
options in use. So, this "switch" between developer mode, and user mode
during your day of developer happens very fast. Bang..exit..boom...you
switched. This can occur VERY fast......pooof! ...you are now in developer
mode....pooof! you are now in user mode to test things.
So, really, you don't need any code to "switch" or "set" the startup
options...just leave them set all the time, and use the shift key to by-pass
them when you develop.
Ok, now you spent the day developing, and are ready to deploy the new
changes. So, you now create the mde file, AND THEN lock out the shift key
by-pass on this mde file. It is this new mde that you distribute to EACH
users workstation. (you are running a split database..right?..as you can't
really develop any other way). So, with this approach you NEVER have to
worry about setting the shift key on your development version, as you allow
the shift by-pass. Further, you NEVER worry about setting (or forgetting to)
the MANY MANY startup options. So, no worry about shift key setting, no
worry about startup options, and this whole approach takes NO code on your
part!! The only thing you will need is a option to disable the shift key
stuff.
You can use mine here:
http://www.attcanada.net/~kallal.msn/msaccess/msaccess.html
Or, on one of your "password" forms that only you can use, simply place a
button that you click on to run the code to dis-able the shift key.
This way I could lockup the db and only if you know the password be able
to unlock it via the startup form.
Do remember, that setting, or changing the startup options requires you to
exit, and then re-enter the database. Why not just set all the startup
options you need, and then leave them (they are VERY easy to forget to set
back...and this will be a constant source of you having to change that stuff
every time you want to work....WAY WAY too much stuff to worry about).
Why not just eliminate all your needs to build some code or software that
lets you "use", or "change" the startup options? Why not just hold down the
shift key during startup for development. After a bit of time, this shift
key will be come complete instinct, and you will not even think about it.
Of course, your users will get the recommend and time honored "mde" file
that developers give to their users anyway.
I just wanted to give you a feel for how a lot of developers deal with
setting the startup options, and as mentioned, the best solution is not to
change them at all for your development process.
Of course, the above process don't work unless you have a split database,
but then again, it VERY hard to see how any development on a application can
occur without having a split database. You can read up on splitting here:
http://www.granite.ab.ca/access/splitapp.htm
Anyway, to answer your question, you can launch the startup options form
with the following code behind a button:
application.RunCommand acCmdStartupProperties
