Disabling Movement to Another Record

[Steve Dunn]

I have a form that displays companies information. When
the user starts to edit a record, I want them to save or
cancel changes before allowing them to move to another
record. I have command buttons cmdNext, cmdPrev and
cmdAddCompany that I disable and cmdSave and cmdCancel
that I enable when an unsaved / uncancelled record exists.
I am thinking that there has to be an easier 'cleaner'
way than this to control the record movement but this
does seem to work.

However, my major problem is how do I keep the user from
moving to another record by using pageup, pagedown, ctrl
home, etc, etc?

thasnks!!

 

[Rick Brandt]

I have a form that displays companies information. When
the user starts to edit a record, I want them to save or
cancel changes before allowing them to move to another
record. I have command buttons cmdNext, cmdPrev and
cmdAddCompany that I disable and cmdSave and cmdCancel
that I enable when an unsaved / uncancelled record exists.
I am thinking that there has to be an easier 'cleaner'
way than this to control the record movement but this
does seem to work.

However, my major problem is how do I keep the user from
moving to another record by using pageup, pagedown, ctrl
home, etc, etc?

Generally when you want this level of control (unnecessary IMO) then you
are better off using an unbound form. You retrieve the data in a Recordset
and push the fields into your controls, then use an update or insert query
to write the changes back to the table. Since the form is unbound there
*are no other records* for the user to navigate to and the only way for
changes to be applied is through your code so you don't have to worry about
all of the various events that might cause the record to be saved as in a
bound form. This is an order of magnitude more difficult when you need a
form/subform though.

You can stay with a bound form and just use the BeforeUpdate event to
prompt the user with a "Are you sure you want to change this record?"
message and setting Cancel = True if the reply with "No". The disadvantage
is that if the update was initiated by a navigation or close, then the user
saying "No" to the save prompt also causes the original action to also be
cancelled. Then they (or your code) have to undo the changes and
reinitiate the original action they were attempting. These types of
systems are very annoying to use, especially for more advanced users.

 

[Tom Menacher]

I always used the cmdNext cmdPrev design.
You also want to set the Form Key Preview property to True,
and then write some code for the Sub Form_KeyDown() for
example:

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

Select Case KeyCode
Case 33, 34 ' page up & page down keys?
KeyCode = 0 ' cancel out the key code

End Select
End Sub

 

[Rick Brandt]

I always used the cmdNext cmdPrev design.
You also want to set the Form Key Preview property to True,
and then write some code for the Sub Form_KeyDown() for
example:

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

Select Case KeyCode
Case 33, 34 ' page up & page down keys?
KeyCode = 0 ' cancel out the key code

End Select
End Sub

But wouldn't you also have to disable the ability to...

Apply a sort
Remove existing sort
Apply a filter
Remove existing filter
Edit Go-To (on main menu)

All of those things can take the user to a different record.