[AccessD] Turning off toolbars in production db.

I've done a similar thing with 2 transparent command buttons shrunk down to
very small and placed in the common form that I use for system information,
version, settings, contact info, etc. I put a small control tip so I know
when I'm over the spot and use the double click event to fire it.

They are basically a GUI backdoor which opens up or locks down access as
much as possible.

HTH
JB

> -----Original Message-----
> From: accessd-bounces at databaseadvisors.com
> [mailto:accessd-bounces at databaseadvisors.com]On Behalf Of John Sullivan
> Sent: Monday, October 20, 2003 3:42 PM
> To: Access Developers discussion and problem solving
> Subject: Re: [AccessD] Turning off toolbars in production db.
>
>
> John and List,
>
> Sorry for coming in to this so late but had an interview, wish me luck.
>
> In a previous position managing support personnel and as default
> application developer, I handled this problem by creating 2 "hidden"
> buttons on a form deep in the application.  The buttons' On_Click events
> called code that would set or unset properties as needed.
>
> Prior to distribution, the "Set" startup button was clicked and the app
> compiled to disable options that allowed the user to shoot ourselves in
> the foot. If support people (most usually me) had to have more access on
> a user's machine, the "UnSet" button in the app was clicked, the app was
> closed and, then re-opened to allow maintenance and correction. On the
> way out, clicking on the "Set" button and closing the app reset the
> conditions for "protecting" the app again before allowing the user back
> in.  Not elegant I know, but it allow some security while fulfilling
> questionable "requirements" such as hiding embedded paths and passwords
> and disallowing the user to see code. A couple of drawbacks, it requires
> the developer/support person to remember to reset the options and the
> changes don't take effect until closing and re-opening the app.  One
> could make the "Set" option fire when the app is opened but I was not
> allowed to take that tactic.
>
> I no longer have access to a copy of this app but I did save some of
> the stripped-down code and am willing to share. You will need to re-add
> error handling and choose your own properties to be toggled but this
> will give a demo of programatticly setting options using the
> Database.Properties method. This was a few years back but I remember  we
> used this in apps of both A97 and A2K.  I also remember having to add
> code to save the user's preferences before making changes and resetting
> those when closing the app for our Access "power" users (the ones who
> most frequently caused problems).
>
> Since the code is long, I prefer to send it offline and would be happy
> for it to be stored on a web site where all list members can download it
> and make fun of it.  This could be an interesting article Susan (hint,
> hint).
>
> John Sullivan
>
> John Colby wrote:
>
> >One of the things I would like to do is turn off the toolbars
> AUTOMATICALLY
> >when the db is in production.  It occurred to me I could use my
> >Workstation() function to sense the name of my dev machine and turn the
> >toolbars off if the db is opening on any other machine.  Has anyone ever
> >done this?  Any thoughts on the matter?
> >
> >John W. Colby
> >www.colbyconsulting.com
> >
> >
> >_______________________________________________
> >AccessD mailing list
> >AccessD at databaseadvisors.com
> >http://databaseadvisors.com/mailman/listinfo/accessd
> >Website: http://www.databaseadvisors.com
> >
> >
> >
>
> _______________________________________________
> AccessD mailing list
> AccessD at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/accessd
> Website: http://www.databaseadvisors.com
>
>