Prevent Design View

I'd like to prevent users from accidently going into design view of a form
and screwing it up.
I've googled the group and have found that the normal method is to use MDE
or user level security. I'd like to avoid both of those options as I'm only
trying to stop accidental changes, not willful misconduct. These mdb's are
too quick/simple to over program.

Now, I have found that the following code works, but I'd like to get your
opinions.

Private Sub Form_Unload(Cancel As Integer)
On Error Resume Next
DoCmd.Close
On Error GoTo 0
End Sub

I understand that if the user gets the database window, they can open the
form in design view. That's fine, I'll can live with that. I just want code
such that if they are changing from datasheet view to form view or back; and
they accidently click on the "green triangle", the form will just close
instead of opening in design view.

Any forseeable problems with this?
TIA
Fred Zuckerman

re: Prevent Design View

> I'd like to prevent users from accidently going into design view of a form[color=blue]
> and screwing it up.[/color]

What's wrong with the mde option?? IMO It is perfect for the option you need
It is build in. It works all right.
They just *can't* screw up your design, neither accidently nor on purpose.

Arno R

re: Prevent Design View

"Arno R" <arraNOcomSPAM@tiscali.nl> wrote in message
news:4390e412$0$2346$ba620dc5@text.nova.planet.nl. ..[color=blue]
> I'd like to prevent users from accidently going into design view of a form
> and screwing it up.[/color]

What's wrong with the mde option?? IMO It is perfect for the option you need
It is build in. It works all right.
They just *can't* screw up your design, neither accidently nor on purpose.
Arno R

You're correct, except that it requires that the mdb be kept around
someplace. I only visit this client occasionaly. Plus they DO have 1-2
people that "could" make design changes. Primarily, though, their normal
users don't have a clue. So, if there were an mdb, then I'd probably need to
keep it (or they might lose it) and then I'd be "tied" to their operation.
Fred

re: Prevent Design View

As mentioned, the mde is the way to go (however, this does assume you have a
split database...you REALLY need to do that for any kind of software
updates).

Another approach is to simply hide the ms-access interface via
tools->startup....

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/AlbertKal...s/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/AlbertKal.../msaccess.html

In the tools->startup..if you disable shortcut menus..then no "design" will
be allowed....



--
Albert D. Kallal (Access MVP)
Edmonton, Alberta Canada
pleaseNOOSpamKallal@msn.com
http://www.members.shaw.ca/AlbertKallal

re: Prevent Design View

Fred Zuckerman wrote in message
<x55kf.35267$6e1.12843@newssvr14.news.prodigy.co m> :[color=blue]
> I'd like to prevent users from accidently going into design view of a form
> and screwing it up.
> I've googled the group and have found that the normal method is to use MDE
> or user level security. I'd like to avoid both of those options as I'm only
> trying to stop accidental changes, not willful misconduct. These mdb's are
> too quick/simple to over program.
>
> Now, I have found that the following code works, but I'd like to get your
> opinions.
>
> Private Sub Form_Unload(Cancel As Integer)
> On Error Resume Next
> DoCmd.Close
> On Error GoTo 0
> End Sub
>
> I understand that if the user gets the database window, they can open the
> form in design view. That's fine, I'll can live with that. I just want code
> such that if they are changing from datasheet view to form view or back; and
> they accidently click on the "green triangle", the form will just close
> instead of opening in design view.
>
> Any forseeable problems with this?
> TIA
> Fred Zuckerman[/color]

I agree about using mde, but to offer some comments on your approach

I don't know if I can give any good explanations of why, but I don't
like using
docmd.close within a routine where it's alredy closing, don't ask me
why, I
can't give any good reasons - just preference? ;-)

I would suggest qualifying the close, should you use it, i e

DoCmd.Close acForm, me.name

In stead of the above, I'd considered expanding this a bit, using the
approach of having your own close button, in which you toggle a boolean
variable with form class module scope, which will then be assigned the
cancel parameter in the unload event.

See
http://www.mvps.org/access/general/gen0005.htm
for some more info

--
Roy-Vidar

re: Prevent Design View

I agree that splitting the DB to FE/BE is the way to go.

But there're few occasions that I would prefer to keep data and program
in one file, mainly for simplicity. And I heard that MDE is less stable
than MDB for data. Is this true?

Eddy S.

re: Prevent Design View

"Fred Zuckerman" <ZuckermanF@sbcglobal.net> wrote
[color=blue][color=green][color=darkred]
>>> I'd like to prevent users from accidently going into design view of a
>>> form
>>> and screwing it up.[/color][/color]
>[color=green]
>> What's wrong with the mde option?? IMO It is perfect for the option you
>> need
>> It is build in. It works all right.
>> They just *can't* screw up your design, neither accidently nor on
>> purpose.
>> Arno R[/color][/color]
[color=blue]
> You're correct, except that it requires that the mdb be kept around
> someplace. I only visit this client occasionaly. Plus they DO have 1-2
> people that "could" make design changes. Primarily, though, their normal
> users don't have a clue. So, if there were an mdb, then I'd probably need
> to
> keep it (or they might lose it) and then I'd be "tied" to their operation.[/color]

If you don't keep a separate development copy of the MDB, anyway, you are
taking a serious risk of disrupting your client's business in case of an
error (which might be totally beyond your control).

Don't ask me what the legal ramifications might be -- I am not a lawyer; I
am talking about business risk, not legal risk, here.

Larry Linson
Microsoft Access MVP

re: Prevent Design View

"Eddy S." <eddysgp@yahoo.com> wrote
[color=blue]
>I agree that splitting the DB to FE/BE is the way to go.
>
> But there're few occasions that I would prefer to keep data and program
> in one file, mainly for simplicity. And I heard that MDE is less stable
> than MDB for data. Is this true?[/color]

I'm not at all sure what "MDE is less stable than MDB for data" even
_means_.

Making an MDE prevents going into design view on Forms, Reports, and
Modules. It does not "protect" anything else -- only those objects which
are, or have, Modules. AFAIK, it should have no effect on Tables,
Relationships, Queries, or Macros.

Larry Linson
Microsoft Access MVP

re: Prevent Design View

Larry Linson wrote:[color=blue]
> I'm not at all sure what "MDE is less stable than MDB for data" even
> _means_.[/color]

What I mean is that I've come across comment/post that when data is
stored in the MDE format the chance of DB corruption is somewhat higher
that storing the data in MDB format.

But I can't be certain that the comment/post is correct... So I was
hoping that some one who's more familiar with the subject could
confirm.

Eddy S.