[AccessD] A2K - setting a form invisible on open

Hi John

> When I say table wizard, I am not taking about the thing that opens
> pre-existing tables and allows you to modify them.  The widget you use to
> design tables (click the table tab in A2K and select New) is a WIZARD!  The
> thing you use to design queries (select the query tab and click NEW) is a
> WIZARD.  It is a piece of VB code, stored in MDAs, registered with Access.
> It is NOT part of Access per se.

> That is also what I am designing, a WIZARD.

Yeah, I know. I don't use them. I just can't see no problem in
creating a table in design view adding comments to the fields; I find
it to be waste of time to select some "example table" and use more
time to check and correct than to create from scratch. The same goes
for the query wizards - it's faster when you know what to do, to open
design view initially. 

> As for different worlds, apparently we do.  If you truly believe that no
> developer out there runs into users who poke and pry then I would love to
> live in your world.

You would be most welcome! But as I wrote, to make a near bulletproof
app you will need Access security. If less can do it - and that must
be the purpose of your LWS system - you can do many things:

A. Design LWS as a user control and guidance system for the behaved
user and user environment. If users are not behaved go to Access
security.

B. Take precautions to prevent accidental user errors. This is the
other side of security: to prevent users from doing things they don't
want to do by accident or error. Many things can be done for free:

1. Rename the app to anything else than mdb or adp. I use mdp. Most
users wouldn't have a clue what an mdp file is. If they doubleclick it
nothing happens.

2. Create your app to be able to run write protected and let your
install routine write protect the file (or you can let your app check
if it itself is write protected; if not, write protect and shut down).
Only a fraction of users have any idea of how to remove write
protection from a file.

3. Apply a database password to the app. This forces the user to run
the app from a shortcut with the password command line switch. Again,
if the user by accident doubleclick the file he/she will be prompted
for a password. No big deal but it will be apparent that "this is not
normal".

4. Run the app in the runtime environment. You can check from within
the app if this is so; if not, pop a message and shut down.

5. Set the startup options to the minimum level, and always hide the
database window as the first task in your start/autoexec code.

You know these things, but others may benefit from these simple
advices and reminders.

/gustav


> John W. Colby

> -----Original Message-----
> From: accessd-bounces at databaseadvisors.com
> [mailto:accessd-bounces at databaseadvisors.com]On Behalf Of Gustav Brock
> Sent: Tuesday, November 11, 2003 11:54 AM
> To: Access Developers discussion and problem solving
> Subject: Re: [AccessD] A2K - setting a form invisible on open


> Hi John

> Well, we must live in different worlds. Most of our users are in
> runtime environments and even those with full versions of Access
> don't fool around with the apps - and they indeed "don't just open
> forms" - they use the UI.

> If wild users is the developer's concern, a LWS tool is not an option
> - his/hers only way to go is full Access security - if not applied,
> these users will, of course, find your LWS tables.

> Also, I've used the table wizard once - and that was it. The only
> wizards I've found a use for are that for creating a simple report and
> that for creating a group box. The Access switch board and the table
> structure behind it is terrible; I've found it just as quick to design
> a main form for that purpose and a single table or two holding the
> user level security.

> I'm not saying there isn't a need for a LWS system, just that it will
> not fully block the scenarios you draw which means you could pay less
> attention to those extremes. How many users know a form can be hidden?
> Not to say how to locate a hidden form and unhide it? Why should they?
> Most users have work to do.