Re: setting and clearing record dirty (A 2007)



"BBC via AccessMonster.com" <u49322@uwe> wrote in message news:996faeabb7a5e@xxxxxx
Well have made some progress but things still happen I can't trace or don't
understand. I'm not even clear on why some of the changes I've made have
made it better (scary). I keep wondering if the Form_BeforeUpdate is a place
I can get control of things but any attempts to set CANCEL=TRUE under
specific circumstance has led to errors message on one or other of my NEW,
SAVE,UNDO DELETE commands
A couple of hurdles that are currently causing some grief are:
A) A new record is entered and ends up in one of 2 known states;
1) it is dirty but not been saved yet
2) dirty and has been saved
The user now decides to abandon this record completely (wants to get rid of
it). How do I eliminate (delete) that record and make the screen blank for
the next/new record for each case above.

For scenario 1 it does
-my own delete warning message
-executes my delete code
( but the record IS actually added to the DB although
never actively saved (by my code) and it ALSO REMAINS visable on
the form)

For scenario 2 it does
-my delete warning message (yes)
-the record then goes NEW (the primary key says NEW)
-then the system delete warning message appears (You are about to delete 1
records) (yes)
-then gives "The command or action DeleteRecord is not available now" (ok)
-then goes back to a normal state with a NEW record
-the record is not in the DB
--So scenario 2 sort of works but I get the system warning and then the
error message, almost like it's doing it twice

Private Sub fDeleteRecd_Click()
Dim Answr As Integer
Answr = DeleteOK(RecdDirty) ' my "is OK to delete" message
If Answr = vbOK Then
On Error GoTo fDeleteRecd_Click_Err
DoCmd.RunCommand acCmdDeleteRecord
End If

' If (Form.NewRecord Or Not Form.Dirty) Then Beep ' testing point
Call frmDirty(False, NoNavigation) 'enable navigation & other controls
(in this case nothing)
Exit Sub

fDeleteRecd_Click_Err:
MsgBox Error$
End Sub

Any suggestions appreciated (some of the automatic things Access does are
very painful)


Without seeing all the code in the form's module -- and no, I don't want to <g> -- I can't say for sure exactly what's happening with your form. However, I can make a suggestion for how to handle the situation you describe with your delete button. Specifically, you want the current record to "go away", regardless of whether it's a new record or an existing record, and whether it's dirty or not -- and you don't want to generate an error if you're already on the new record and it hasn't been modified yet.

For this purpose, the general logic to follow is this:

If you're on a new record and it's not dirty, do nothing
Else
If (user confirms the delete) Then
Undo and changes to the current record.
If you're on a new record, you're done
Else
Delete the current record
Go to the new record (or whatever record you want)
End If
End If
End If

Here's an attempt to adapt your code for fDeleteRecd_Click to this logic:

'------ start of revised code ------
Private Sub fDeleteRecd_Click()

On Error GoTo Error_Handler

If Me.NewRecord And Not Me.Dirty Then
' Do nothing; there's nothing to delete.
Else
If DeleteOK(RecdDirty) = vbOK Then

' Undo any pending changes to this record.
Me.Undo

' If we're on the new record, we're done.
' If we're on an existing record, delete it.
If Not Me.NewRecord Then
' Turn off warnings so the user doesn't get a second prompt.
DoCmd.SetWarnings False
RunCommand acCmdDeleteRecord
' Turn warnings back on.
DoCmd.SetWarnings True
' Go to a new record. Ignore error if we're there already.
On Error Resume Next
RunCommand acCmdRecordsGoToNew
End If

'enable navigation & other controls (in this case nothing)
Call frmDirty(False, NoNavigation)

End If
End If

Exit_Point:
Exit Sub

Error_Handler:
' Don't let the routine exit without turning warnings back on.
DoCmd.SetWarnings True
' Display error message.
MsgBox Error$
Resume at the routine's cleanup point.
Resume Exit_Point

End Sub
'------ end of revised code ------

Now, I can make no promises about this code, because there could easily be things I don't understand about your form and the rest of your code. But you should at least see how this version implements the necessary logic.

--
Dirk Goldgar, MS Access MVP
www.datagnostics.com

(please reply to the newsgroup)

.


Loading