Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations Chriss Miller on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
How to tell when bound form is on last record
- Thread starter diwin
- Start date
TheAceMan1
Programmer
How are ya diwin . . .
Perhaps:
[blue]Your Thoughts? ... [/blue]
See Ya! . . . . . .
Be sure to see thread181-473997 [blue]Worthy Reading![/blue]![[thumbsup2]](/data/assets/smilies/thumbsup2.gif "[thumbsup2] [thumbsup2]")
Also faq181-2886 [blue]Worthy Reading![/blue]
Perhaps:
Code:
[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]
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:
Bob Larson
FORMER Microsoft Access MVP (2008-2009, 2009-2010)
Free Tutorials/Samples/Tools:
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.
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.
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:
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:
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.
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:
Bob Larson
FORMER Microsoft Access MVP (2008-2009, 2009-2010)
Free Tutorials/Samples/Tools:
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:
Bob Larson
FORMER Microsoft Access MVP (2008-2009, 2009-2010)
Free Tutorials/Samples/Tools:
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
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
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
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
Programmer
diwin . . .
Have you reached resolution?
See Ya! . . . . . .
Be sure to see thread181-473997 [blue]Worthy Reading![/blue]
Also faq181-2886 [blue]Worthy Reading![/blue]
Have you reached resolution?
See Ya! . . . . . .
Be sure to see thread181-473997 [blue]Worthy Reading![/blue]
Also faq181-2886 [blue]Worthy Reading![/blue]
- Status
Similar threads
