Idiot proof!

[Jeff Klein]

Is there a way to stop the form from scrolling records in the table that it
is sourced to. I have my form opening and going to new record and I don't
want the user to accidentally backup to the previous record. I have
disabled the Nav buttons but certain keystrokes will also scroll records.
Page up and page down are the ones I know of but there are probably more.

 

[Brendan Reynolds]

You need to set the form's Key Preview property to 'Yes' for the following
code to work ...

Private Sub Form_KeyDown(KeyCode As Integer, Shift As Integer)

Select Case KeyCode
Case vbKeyPageUp, vbKeyPageDown
KeyCode = 0
Case vbKeyUp, vbKeyDown, vbKeyHome, vbKeyEnd
If Shift And acCtrlMask Then
KeyCode = 0
End If
End Select

End Sub

--
Brendan Reynolds (MVP)
http://brenreyn.blogspot.com

The spammers and script-kiddies have succeeded in making it impossible for
me to use a real e-mail address in public newsgroups. E-mail replies to
this post will be deleted without being read. Any e-mail claiming to be
from brenreyn at indigo dot ie that is not digitally signed by me with a
GlobalSign digital certificate is a forgery and should be deleted without
being read. Follow-up questions should in general be posted to the
newsgroup, but if you have a good reason to send me e-mail, you'll find
a useable e-mail address at the URL above.

 

[PC Datasheet]

Jeff,

Open your form in design view, open properties, go to the Data tab and set
Data Entry to Yes.

 

[Roger Carlson]

Try setting the form's Cycle property to "Current Record"

--
--Roger Carlson
www.rogersaccesslibrary.com
Want answers to your Access questions in your Email?
Free subscription:
http://peach.ease.lsoft.com/scripts/wa.exe?SUBED1=ACCESS-L

 

[Jimmy]

Roger's suggestion is the best suggestion because it will
work on forms with the data entry property set to yes and
no. It more flexible and addresses your issue exactly.

Thanks,

Jim

 

[Jim Allensworth]

Roger's suggestion is the best suggestion because it will
work on forms with the data entry property set to yes and
no. It more flexible and addresses your issue exactly.

Not really.

The Cycle property has no bearing on {Page Up} or {Page Down} among
others.

You need to manage the keystrokes as Brendan Reynolds posted.

- Jim

 

[Rick Brandt]

Roger's suggestion is the best suggestion because it will
work on forms with the data entry property set to yes and
no. It more flexible and addresses your issue exactly.

It doesn't stop the user from removing or applying a filter or using the
Pageup and Pagedown keys. It really depends on just how "accidental" these
navigations are and how strongly you want to prevent them.

The surest way is to bind the form to a RecordSource like...

SELECT * From YourTable WHERE 1 = 0

This will open at a blank new record (just like setting DataEntry to True)
but the user has absolutely no other records that they can go to by any
method available in the GUI.

 

[Roger Carlson]

I had forgotten [PGUP] and [PGDN].

However, setting DataEntry to Yes and adding a Requery to the AfterInsert
event:

Private Sub Form_AfterInsert()
Me.Requery
End Sub

handles every situation I can imagine.

--
--Roger Carlson
www.rogersaccesslibrary.com
Want answers to your Access questions in your Email?
Free subscription:
http://peach.ease.lsoft.com/scripts/wa.exe?SUBED1=ACCESS-L

 

[Rick Brandt]

I had forgotten [PGUP] and [PGDN].

However, setting DataEntry to Yes and adding a Requery to the AfterInsert
event:

Private Sub Form_AfterInsert()
Me.Requery
End Sub

handles every situation I can imagine.

Except removing all filters which would then load all of the records in the
Recordset.

 

[Roger Carlson]

You ARE sneaky! <grin>

But I think your other point has merit as well. Are we talking Idiot
Proofing or Mischief Proofing? I think even the business of [PGUP] and
[PGDN] is a little far-fetched for an accident. Tabbing, Enter Key, Arrow
Keys, I can see, but who pages in an app? Especially in forms that don't
use pages?

If you really want to lock down the app: add Access Security, make the forms
unbound, make the app an MDE, remove all the standard menus, hide the
Database window, disable the Shift override... or maybe switch to VB and
compile it into an executable.

I try to remove as many ways for the user to make a mistake as possible.
But I don't try to make the app mischief-proof. I personally feel that that
is a management function. If a user can't be trained not to deliberately
sabotage an application, then he or she should be fired.

--
--Roger Carlson
www.rogersaccesslibrary.com
Want answers to your Access questions in your Email?
Free subscription:
http://peach.ease.lsoft.com/scripts/wa.exe?SUBED1=ACCESS-L

I had forgotten [PGUP] and [PGDN].

However, setting DataEntry to Yes and adding a Requery to the AfterInsert
event:

Private Sub Form_AfterInsert()
Me.Requery
End Sub

handles every situation I can imagine.

Except removing all filters which would then load all of the records in the
Recordset.

 

[Jeff Klein]

I'm with Roger.....Idiot Proof = Fire Idiot
Next question. What if the user is your spouse?

I will mull over all the suggestions that have been made. I am sure I can
find a reasonable solution from your replies. Thanks everyone!

You ARE sneaky! <grin>

But I think your other point has merit as well. Are we talking Idiot
Proofing or Mischief Proofing? I think even the business of [PGUP] and
[PGDN] is a little far-fetched for an accident. Tabbing, Enter Key, Arrow
Keys, I can see, but who pages in an app? Especially in forms that don't
use pages?

If you really want to lock down the app: add Access Security, make the forms
unbound, make the app an MDE, remove all the standard menus, hide the
Database window, disable the Shift override... or maybe switch to VB and
compile it into an executable.

I try to remove as many ways for the user to make a mistake as possible.
But I don't try to make the app mischief-proof. I personally feel that that
is a management function. If a user can't be trained not to deliberately
sabotage an application, then he or she should be fired.

--
--Roger Carlson
www.rogersaccesslibrary.com
Want answers to your Access questions in your Email?
Free subscription:
http://peach.ease.lsoft.com/scripts/wa.exe?SUBED1=ACCESS-L

I had forgotten [PGUP] and [PGDN].

However, setting DataEntry to Yes and adding a Requery to the AfterInsert
event:

Private Sub Form_AfterInsert()
Me.Requery
End Sub

handles every situation I can imagine.

Except removing all filters which would then load all of the records in the
Recordset.

 

[Immanuel Sibero]

Next question. What if the user is your spouse?

Ha, this just brightened my day...
You're not saying your spouse is an idiot, are you?

Immanuel Sibero

I'm with Roger.....Idiot Proof = Fire Idiot
Next question. What if the user is your spouse?

I will mull over all the suggestions that have been made. I am sure I can
find a reasonable solution from your replies. Thanks everyone!

You ARE sneaky! <grin>

But I think your other point has merit as well. Are we talking Idiot
Proofing or Mischief Proofing? I think even the business of [PGUP] and
[PGDN] is a little far-fetched for an accident. Tabbing, Enter Key, Arrow
Keys, I can see, but who pages in an app? Especially in forms that don't
use pages?

If you really want to lock down the app: add Access Security, make the forms
unbound, make the app an MDE, remove all the standard menus, hide the
Database window, disable the Shift override... or maybe switch to VB and
compile it into an executable.

I try to remove as many ways for the user to make a mistake as possible.
But I don't try to make the app mischief-proof. I personally feel that that
is a management function. If a user can't be trained not to deliberately
sabotage an application, then he or she should be fired.

--
--Roger Carlson
www.rogersaccesslibrary.com
Want answers to your Access questions in your Email?
Free subscription:
http://peach.ease.lsoft.com/scripts/wa.exe?SUBED1=ACCESS-L

I had forgotten [PGUP] and [PGDN].

However, setting DataEntry to Yes and adding a Requery to the AfterInsert
event:

Private Sub Form_AfterInsert()
Me.Requery
End Sub

handles every situation I can imagine.

Except removing all filters which would then load all of the records

in
the

Recordset.