Page Down key

  • Thread starter Thread starter Glynn
  • Start date Start date
G

Glynn

Can I disable this key.
On my Form I have a SAVE command button, which performs the Save and Close
function. If however the User clicks on the PageDown key the screen moves to
a new blank record - which I do not want.

How can I prevent the PageDown key from hi-jacking my form.
 
Glynn, there are dozens of ways that the record can be saved other than your
SAVE button. PgDn, PgUp are a couple of them. Other examples:
- tabbing past the last text box on the form
- using the navigation buttons
- keyboard shortcuts (Shift+Enter)
- menu/toolbar/ribbon commands/shortcuts/buttons
- applying a filter
- changing the sort order
- closing the form
- closing the database
- closing Access
- moving focus into/out of a subform
and so on.

You can use the KeyDown event of the *form* (with KeyPreview on) to discard
the PageDown keystroke, but my point is that this is a much bigger issue
than that.

If you want to run any checks/validation, use the BeforeUpdate event of the
*form*. Access fires this event just before the record is saved, regardless
of what triggers the save. Ultimately you have to work with the built-in
events, rather than try to force everything through a particular funnel.
 
Hi Glynn,
in addition to Allen's excellent answer, there are a couple of things you
can do.
If your form has allow additions and allow data entry set to no, you can
open the form to add a single new record by
DoCmd.OpenForm [NameOfForm], DataMode:=acFormAdd

If you want only edits, you can set allow additions to no and pagedown will
not go to a new blank record.


Jeanette Cunningham MS Access MVP -- Melbourne Victoria Australia
 
Allen - Regretfully you are dealing with a dummy.
I would like to use your Keydown event to discard the PageDown keystroke,
but I have been unable to figure out just how to do this.

Can you give me some more clues, or step by step entry.

At present I'm using 'DoCmd.SelectAllRecords' then 'DoCmd.DeleteRecord', in
the 'BeforeUpdate' event which appears to do the job (but leaves the User a
littel bit in the dark') - and which I hope does not come back to bite me
someday.

Appreciate your help.
 
Jeanette - Thanks, but my Form has the 'Allow additions' and Allow data
entry' set to YES so I've not been able to avail myself of this option.

See also my reply to Allen
--
Glynn


Jeanette Cunningham said:
Hi Glynn,
in addition to Allen's excellent answer, there are a couple of things you
can do.
If your form has allow additions and allow data entry set to no, you can
open the form to add a single new record by
DoCmd.OpenForm [NameOfForm], DataMode:=acFormAdd

If you want only edits, you can set allow additions to no and pagedown will
not go to a new blank record.


Jeanette Cunningham MS Access MVP -- Melbourne Victoria Australia

Glynn said:
Can I disable this key.
On my Form I have a SAVE command button, which performs the Save and Close
function. If however the User clicks on the PageDown key the screen moves
to
a new blank record - which I do not want.

How can I prevent the PageDown key from hi-jacking my form.
Click to expand...
Click to expand...
 
1. Open the form in design view.

2. Open the Properties box.
(Make sure you are looking at the properties of the form, not of a text
box.)

3. On the Event tab of the Properties box, set:
Key Preview Yes
On Key Down [Event Procedure]

4. Click the Build button (...) beside On Key Down.
Access opens the code window.
Add this line of code between the other two:

Private Sub Form_KeyDown(KeyCode As Integer, Shift As Integer)
If KeyCode = vbKeyDown Then KeyCode = 0
End Sub
 
Thanks Allen - Now working fine.
I am in Access 2003 and needsed to insert the Keycode No.
"If KeyCode = 34 Then KeyCode = 0"

Thanks again for your help.
 
Yes: cancelling Form_BeforeUpdate will work if you really must force users
through your particular funnel.

There may be times when you might need to do that, but the vast majority of
times I see people doing this, it's because they don't understand how to
work with the built-in events.
 
If you want to do something at the point when the navigates to a different
record, use Form_Current. (Test Me.NewRecord if you want to see if it's a
new record.)

If you want to do something before a record is saved, use Form_BeforeUpdate.
Example: validation of the record.

If you need to do something else as a consequence of editing/inserting a
record, use Form_AfterUpdate or Form_AfterInsert.

If you want to do something at the point when they start entering a new
record, use Form_BeforeInsert.

If you need to reset a form to its previous state when the user discards
changes, use Form_Undo. Example: showing/hiding controls.

If you need to test or respond to deletions, you need a combination for
Form_Delete, Form_BeforeDelConfirm, and Form_AfterDelConfirm. (These are a
bit more complex, as it's possible to select several records and delete them
in one go.)

In general, I don't bother coding buttons for next, previous, save, new, or
undo. The built-in ones work better and are more flexible, and you can put
them on a toolbar or ribbon and use them with any form.

Particularly, undo on a form (rather than toolbar/ribbon) works poorly: if
you have an incomplete value (e.g. if you have typed 2/2/ into a date
field), you can't get out of the text box to get to the button on your form,
but you can get to the toolbar/ribbon button.

HTH

--
Allen Browne - Microsoft MVP. Perth, Western Australia

Reply to group, rather than allenbrowne at mvps dot org.


BBC via AccessMonster.com said:
I agree, you are absolutely right, I'm not fully aware of events
particularly
around record navigation, saving records, new records, undo etc., and I
know
this is the big hammer method. I am hopefully getting to be an
intermediate
at Access but I have spent probably 100s of hours just trying to get to a
solid set of record navigation functions working (next, previous, save,
new,
undo, integrated with managing "dirty" records...). I have many Access
books
(beginner, Intermediate. Advanced and not one of them treats "navigation"
adequately, at best, bits & pieces) and I have looked at many Forums &
Access
sites, submitted numerous questions but have not found much help in
actually
designing a fully functional solution. I you know of somewhere I can find
some solid practical information with some good examples that would be
great.
I'm pretty good at working through and understanding sample code.
Don't mean to whine, but how hard should this be?
Thanks for input and as I mentioned a few days ago to you, Great Web Site

Allen said:
Yes: cancelling Form_BeforeUpdate will work if you really must force users
through your particular funnel.

There may be times when you might need to do that, but the vast majority
of
times I see people doing this, it's because they don't understand how to
work with the built-in events.
Have a similar issue and want ONLY my save button to save records. Was
wondering if the following strategy might also work.
Click to expand...
[quoted text clipped - 30 lines]
How can I prevent the PageDown key from hi-jacking my form.
Click to expand...
Click to expand...

--
Thanks
Brian

Message posted via AccessMonster.com
Click to expand...
 
Back
Top