How to tell when bound form is on last record

[diwin]

I have created nav buttons on a bound form. I would like to disable the "next" button when on the last record. How do I know when that is true?

Daniel Dillon
O o . (<--- brain shrinking at rate shown.)

 

[PWise]

how about on form current

dim rs
set rs= me.recordsetclone
rs.bookmark=me.bookmark
rs.movenext
if rs.eof then me.cmdnextemabled=false

 

[TheAceMan1]

How are ya diwin . . .

Perhaps:

[blue]   If Me.Recordset.RecordCount = Me.Recordset.AbsolutePosition + 1 Then
      [green]'On Last Record[/green]
   End If[/blue]

[blue]Your Thoughts? ... [/blue]

See Ya! . . . . . .

Be sure to see thread181-473997 [blue]Worthy Reading![/blue]
Also faq181-2886 [blue]Worthy Reading![/blue]

 

[boblarson]

I've always just handled the Error 2105 which occurs when you try to go past the last record.

Bob Larson
FORMER Microsoft Access MVP (2008-2009, 2009-2010)
Free Tutorials/Samples/Tools:

http://www.btabdevelopment.com

 

[MajP]

Bob,
For someone who always preaches and demonstrate good coding principles, I am suprised to see you advocate for using error handling for program flow. I have always been instructed that using error handling for program flow is poor programming. IMO it can mask errors, makes the code hard to understand, and it is inefficient. In many languages throwing exceptions is one of the most expensive operations. In some cases it is just a whole lot simpler to throw the error (i.e. item in a collection), but in this case I cannot see any reason to advocate that method.

 

[boblarson]

MajP -

People always assume that errors are bad. They aren't. In fact, you can use them to your advantage. Now, using On Error Resume Next is a HORRIBLE thing to do as it DOES obscure the cause of many things.

But, look at it this way -

Even Microsoft has determined that ERRORS are not bad. So, in the newer .NET languages we have TRY and CATCH blocks with EXCEPTIONS. They aren't ERRORS per se. They CAN be errors but they are not many times an error but an exception which you wish to catch.

Also, there are times where you might want to RAISE an error so to stop processing in order to handle something. Is that really an ERROR? No, you intended it.

So, if you take that mindset into the Access world, you will see that not all errors are bad and, in fact, you will see that there are many good programmers out there who use errors for good. In this case it is for good and I will continue to use them in that way. They are efficient and you don't have to do any extra checking to see if the recordset is at the end, you just have to TRY and CATCH the EXCEPTION. You deal with the exception that is generated when you can't go on. Actually very efficient.

I hope that helps explain it better. Errors CAN be your friend.

Bob Larson
FORMER Microsoft Access MVP (2008-2009, 2009-2010)
Free Tutorials/Samples/Tools:

http://www.btabdevelopment.com

 

[MajP]

I think that is stretching it a little. Throwing exceptions in .net is definitely not the same as throwing a standard error in vb/vba. The two constructs compile completely differently. I know from experience in Java that even throwing exceptions is an expensive operation. From what I read in standard vb/vba throwing errors is also inefficient. So we will have to agree to disagree on this one. I am just not convinced that in vb/vba throwing errors to support program flow is a good practice, and will continue to discourage novice programmers from doing so.

 

[MajP]

BTW here is an example from a couple of days ago, of why this concept gets people in trouble.
thread705-1633586

 

[boblarson]

Well, I guess we'll have to agree we disagree (as many well-known Access people agree with me, so I have no qualms about it).

Bob Larson
FORMER Microsoft Access MVP (2008-2009, 2009-2010)
Free Tutorials/Samples/Tools:

http://www.btabdevelopment.com

 

[boblarson]

And I'll just stop posting here so that we don't clash further.

Bob Larson
FORMER Microsoft Access MVP (2008-2009, 2009-2010)
Free Tutorials/Samples/Tools:

http://www.btabdevelopment.com

 

[PWise]

While I don"t use Error Traping for program flow there some issues that I don"t know how to trap whit error handling such if a form is used as a sub form or not.

Any one have A method for that without trowing an error

PW

 

[MajP]

Public Function isSubFormLoaded(subFrmName As String) As Boolean
Dim subFrm As Access.Form
Dim frm As Access.Form
Dim ctrl As Access.Control
For Each frm In Forms
For Each ctrl In frm.Controls
If ctrl.ControlType = acSubform Then
If ctrl.SourceObject = subFrmName Then
isSubFormLoaded = True
Exit Function
End If
End If
Next ctrl
Next frm
End Function

 

[MajP]

Here is a better one
Public Function isSubForm(frmIn As Access.Form) As Boolean
'Sub forms are not added to the forms collection
Dim frm As Access.Form
isSubForm = True
For Each frm In Forms
If frm Is frmIn Then
isSubForm = False
End If
Next frm
Exit Function
End Function

 

[TheAceMan1]

diwin . . .

Have you reached resolution?

See Ya! . . . . . .

Be sure to see thread181-473997 [blue]Worthy Reading![/blue]
Also faq181-2886 [blue]Worthy Reading![/blue]