Trapping a GoToRecord event.

[casinc815]

I have a form with a GOTO control arrow on it. Actually two arrows: Previous and Next.
On the Next arrow there is an Event procedure, no macro. The event procedure is
straightforward. It is DoCmd.GotoRecord,,acNext. This is all and good.

I noticed this morning that the arrow was on a split form and am scrolling through the
datasheet when I got to the end of the list (the lsit was 40 records). The next record at the
end of the list is blank. I got an error: "Improper use of null!" The error comes from the field
requirements for those data elements on the form and they exist in the table. No nulls allowed.

To make a long story short, I would like to trap the end of the list and have a more defined
error for the user. Something like: "End of List" that I can program. The way I handled the end
was the short screen that appears with the error message allows you to Debug or End. I simply


pressed End and all was fine and good.

My issue is to trap the end of the list and issue a simple message. Is this straightforward to do?

[aytee111]

Try setting the form property "Allow Additions" to No.

[casinc815]

Try setting the form property "Allow Additions" to No.

Aytee:

Thanks for taking a look at my thread. Your suggestion works like a charm for getting
rid of a confusing notice. The notice that appears says: "Cannot move beyond record!"
This will suffice.

I would still like to know if there is a programmatic way of trapping the message that appears
and modifying the message to be a little softer for the user?

Either way, I have made the modification you have suggested. Thanks Again! - Jim

[Missinglinq]

Here's some code that i routinely use. It 'wraps' back to the first record when reaching the last record, and vice versa; when using the 'previous' button and reaching the first record, it then goes 'back' to the last record.

Private Sub Go2Next_Click()

  If Me.CurrentRecord = Me.RecordsetClone.RecordCount Or Me.NewRecord = True Then
 
    DoCmd.GoToRecord , , acFirst

  Else

    DoCmd.GoToRecord , , acNext

  End If

End Sub

Private Sub Go2Prev_Click()

  If Me.CurrentRecord = 1 Or Me.NewRecord = True Then

    DoCmd.GoToRecord , , acLast

  Else
  
    DoCmd.GoToRecord , , acPrevious

  End If

End Sub

You could replace the lines

DoCmd.GoToRecord , , acFirst

and

DoCmd.GoToRecord , , acLast

with messages boxes, if you prefer, instead of 'wrapping' the recordset.

Linq ;0)>

[casinc815]

Here's some code that i routinely use. It 'wraps' back to the first record when reaching the last record, and vice versa; when using the 'previous' button and reaching the first record, it then goes 'back' to the last record.

Private Sub Go2Next_Click()

  If Me.CurrentRecord = Me.RecordsetClone.RecordCount Or Me.NewRecord = True Then
 
    DoCmd.GoToRecord , , acFirst

  Else

    DoCmd.GoToRecord , , acNext

  End If

End Sub

Private Sub Go2Prev_Click()

  If Me.CurrentRecord = 1 Or Me.NewRecord = True Then

    DoCmd.GoToRecord , , acLast

  Else
  
    DoCmd.GoToRecord , , acPrevious

  End If

End Sub

You could replace the lines

DoCmd.GoToRecord , , acFirst

and

DoCmd.GoToRecord , , acLast

with messages boxes, if you prefer, instead of 'wrapping' the recordset.

Linq ;0)>

I have implemented your code and everything works well. I tried it both ways and allowed the users
to determine their preference. We ended up going with the suggested coding and did not need to use
Message commands. Eveybody like the automatic rotation of the green bar through the datasheet.

Many thanks for your help!

[Missinglinq]

Glad we could help!

Linq ;0)>

[casinc815]

Glad we could help!

Linq ;0)>

I want to thank you for assisting me in resolving my users concerns. Rest
assured you are getting credit. But I opened pandora's box.

In line with this thread, now the user wants to know if the bar that moves
through the records can be made darker or a different color. Your code work
very well. I have searched the literature and the books I have on Access and
it seems no one has ever addressed this issue.

Is the bar on a split form datasheet programmable? So far I cannot find an opinion
one way or another. Your thoughts would be appreciated, again!

Jim

P.S. If you ever get to Chicago, I owe you a beer!

[aytee111]

I'm not sure that I understand which "bar" it is that you are referring to. Could you provide a print screen or something?

[casinc815]

I'm not sure that I understand which "bar" it is that you are referring to. Could you provide a print screen or something?

There is no way to insert an image here. Please contact me at casinc815@hotmail.com. I can forward
a screen shot that way. The size exceeds requirements on this site. Thanks!

Jim

[Missinglinq]

The 'bar' the OP is referring to is the 'Splitter Bar' that is native in the new, to v2007, Split Form, and the answer is No; you're pretty much stuck to either having it present or not. The color for these kind of things is defined by Windows' properties as opposed to properties of a specific app.

Linq ;0)>

[casinc815]

The 'bar' the OP is referring to is the 'Splitter Bar' that is native in the new, to v2007, Split Form, and the answer is No; you're pretty much stuck to either having it present or not. The color for these kind of things is defined by Windows' properties as opposed to properties of a specific app.

Linq ;0)>

Understood! Thanks for your time! I appreciate it! Jim