prevent exit fromcurrent record on continuous sub-form (1 Viewer)

[sonny123]

i have a continuous sub form to which the user adds new records
the validation rules & tab stops vary depending on the value in the first and sometimes the second field of the subform

Problems arise when the user decides to edit a control in previous entry

I am trying to prevent the user from exiting the current record until they reach the final command button on the subform

here is what i have done
but when i get to the caseCost button the form will not tab to the next record

Private Sub Form_Dirty(Cancel As Integer)
isflagUp = True
End Sub

Private Sub Form_BeforeUpdate(Cancel As Integer)
Debug.Print isFlagUp

If (isFlagUp) Then
    MsgBox msgtxt, vbCritical, msgCaption
    Cancel = True
End If

End Sub

Private Sub CaseCost_GotFocus()
isFlagUp = False
Me.CaseCost.ForeColor = vbBlue
Me.Latest_Eligibility_Code.Enabled = False
Me.Latest_Eligibility_Code.Locked = True
Me.Latest_Eligibility_Code.TabStop = False
Debug.Print  isFlagUp

 

[missinglinq]

Have never heard of not saving a Record until a Command Button is 'reached,' whatever that means! But you can't move to the next Record because of these bits

Private Sub Form_Dirty(Cancel As Integer)
isflagUp = True
End Sub

Private Sub Form_BeforeUpdate(Cancel As Integer)
Debug.Print isFlagUp

If (isFlagUp) Then
    MsgBox msgtxt, vbCritical, msgCaption
    Cancel = True
End If
End Sub

When the Record becomes Dirty, you're setting isFlagUp to True, and if isFlagUp is True when you get to the Form_BeforeUpdate event, you're Canceling the Save. The problem is that isFlagUp will always be True, because if the Form is Not Dirty (i.e. isFlagUp is False), the Form_BeforeUpdate event will not fire!

Perhaps a bit more explanation about needing to 'reach the last' Command Button is in order.

Linq ;0)>

 

[sonny123]

stone me !
its working fine now, i ve not tested the form fully to see if i get all the desired effects.

me thinks that even though i ran compile, maybe i didnt save my last little edit before i tested the form


as to why, i want to stop people editing randomly and force them through a tab order because differnt validation rules for differnt values in the first control

my thinking was that all the controls before the cmd button are bound to a table, (the cmd button just opens a SSRS report it does not effect the data in the record)
so i figured that the before update would fire once focus got passed all the bound controls which is why i set it the flag to false when the focus gets to the button.

 

[sonny123]

When the Record becomes Dirty, you're setting isFlagUp to True, and if isFlagUp is True when you get to the Form_BeforeUpdate event, you're Canceling the Save. The problem is that isFlagUp will always be True, because if the Form is Not Dirty (i.e. isFlagUp is False), the Form_BeforeUpdate event will not fire!

okay yes i see, i'm an idiot this event driven stuff is a bit confusing
my code doesnt work
the before update is fired as soon as i try to click out of the current row
and if the flagUp is True then I cannot get out of the record because the record cannot update.

 

[missinglinq]

Not an idiot, simply inexperienced! There's a world of difference between the two!

As a rule, Validation for a given Control, such as a Textbox, is done in the Control's BeforeUpdate event. This would include such things as making sure Numeric data was entered, if appropriate, rather than Text, or that the data had to contain a certain number of characters, and so forth. If the data fails the Validation, you simply set Cancel = True, which makes the Focus stay on the errant Control until appropriate data is entered.

Validation that involves multiple Controls has to go in the Form_BeforeUpdate event. This includes things such as insuring that a EndDate is later than a StartDate, or verifying that if ControlA is populated, ControlB must also have data, etc.

Validation that one or more Controls actually contain data also has to be done in the Form_BeforeUpdate event. Why? Because Validating that a Control actually has data, using one of that Control's events, is useless; all the user has to do is skip the Control entirely, and none of its events will fire!

Once again, if Validation in the Form_BeforeUpdate event fails, you set Cancel = True, which aborts the Save, and tell the user where they've gone wrong, setting Focus back to the offending Control.

In your case, you need to use the Form_BeforeUpdate event to verify that all required Fields contain data, before leaving/saving the Current Record. You could simply mark the Fields as 'Required,' either at the Table or Form level, but most experienced developers avoid this, as the error messages Access gives the users, when Required Fields are left empty can be, shall we say, less than helpful!

Linq ;0)>