Deferring Command Button's Clicked Event Until after Current

[whdyck]

I'm using Access 2003.

I have code that highlights each record selected, based on code that lives in the form's Current event handler and conditional formatting. I also have a button displayed on each record that deletes that record when clicked, but only after displaying a warning.

Problem is that the Current event seems to fire *after* the command button's Clicked event. That means that if the user clicks the Delete button on a record not currently selected, the error message displays, but the highlighted record is not the record to be deleted. This behaviour will tend to confuse the user.

What's the best way to handle this timing issue? I have tried to simply replicate the code in the Current event to the command button's Clicked event, but it doesn't quite work.

Only thing I can think of is to set some type of flag when the user clicks the Delete button, then check for that flag in the Current event. But that seems very klugy. Is there another way?

Thanks.

Wayne

 

[bob fitz]

Can you post a copy of your db that I can play with?

 

[mdlueck]

Two things come to mind.

1) To keep the UI responsive on DB activity which can take as long as HOURS to complete, I have sprinkled:

    'Keep UI responsive
    DoEvents

inside the loop processing records.

2) To force changes back into the table where users are allowed to live edit in a Multiple Items form, I needed to use this solution to insure that what was in the UI was actually also in the database table:

Private Sub addpartrecordflg_AfterUpdate()

  'This will force the UI change back into the table
  If Me.Dirty Then
    Me.Dirty = False
  End If

End Sub

I hope perhaps one of these help you.

 

[whdyck]

Here you go.

I have stripped down the DB to the essentials that show the behavior.

To reproduce the behavior:
1. Open frmLiaErrorCorrection.
2. Click the Delete button on any record except the currently selected one.
3. Notice that the MsgBox appears before the row is highlighted, even though the row selector arrow on the left does point to the correct record when the MsgBox appears.

Maybe I just need a different UI approach for these logical deletes. Suggestions?

Thanks.

Wayne

 

[bob fitz]

This works for me.

Private Sub cmdDeleteLogically_Click()
On Error GoTo ErrorHandler
Dim lngMsgBoxResponse   As Long
Me.chkHoldFlag.SetFocus
[B][COLOR=red]Me.txtCurrent = Me.LiaStageDetailId
Me.Repaint
DoEvents
[/COLOR][/B]
' Display warning only if not already logically deleted
If Me!LiaStatusCode <> "D" Then
    lngMsgBoxResponse = MsgBox("Logically deleting a record is irreversible?" & vbCrLf & vbCrLf & "Are you sure?", vbYesNo, "CWB Logistics")
End If
If lngMsgBoxResponse = vbYes Then
    Call DoCmd.SetWarnings(False)
    Call DoCmd.RunSQL("UPDATE tblLiaStageDetail " & _
                      "SET LiaStatusCode = 'D' " & _
                      "WHERE LiaStageDetailId = " & Me!LiaStageDetailId)
    Call DoCmd.SetWarnings(True)
    Me.Refresh
End If
CleanUpAndExit:
    Exit Sub
ErrorHandler:
    Dim strErrorMessage As String
    strErrorMessage = "Error Number:  " & Err.Number & vbCrLf & _
                      "Description:  " & Err.Description & vbCrLf & _
                      "Source:  " & Err.Source & " in frmStageDetail.cmdDeleteLogically_Click()"
    MsgBox strErrorMessage, , "CWB Logistics"
    Resume CleanUpAndExit
 
End Sub

 

[bob fitz]

I have edited my previous post.

 

[whdyck]

I have edited my previous post.

Thanks for editing your post. I was scratching my head wondering why it wasn't working. But it's working now! Woohoo!

Anyway, kudos to both you and mdlueck.

BTW, any chance of getting a Coles notes of what your additional code does to make this work? (I had tried injecting "Me.txtCurrent = Me.LiaStageDetailId" into the Clicked event, but obviously I needed more.)

Thanks again.

Wayne

 

[bob fitz]

Actually, this line:
Me.txtCurrent = Me.LiaStageDetailId
is not needed.

Of "Repaint", the help file says:

The Repaint method completes any pending screen updates for a specified form. When performed on a form, the Repaint method also completes any pending recalculations of the form's controls.

So this gets access to apply the conditional formating but the code runs faster than the screen can update, so we use DoEvents, of which the help file says:

Yields execution so that the operating system can process other events.
Syntax
DoEvents( )
Remarks
The DoEvents function returns an Integer representing the number of open forms in stand-alone versions of Visual Basic, such as Visual Basic, Professional Edition. DoEvents returns zero in all other applications.
DoEvents passes control to the operating system. Control is returned after the operating system has finished processing the events in its queue and all keys in the SendKeys queue have been sent.
DoEvents is most useful for simple things like allowing a user to cancel a process after it has started, for example a search for a file. For long-running processes, yielding the processor is better accomplished by using a Timer or delegating the task to an ActiveX EXE component.. In the latter case, the task can continue completely independent of your application, and the operating system takes case of multitasking and time slicing.
Caution Any time you temporarily yield the processor within an event procedure, make sure the procedure is not executed again from a different part of your code before the first call returns; this could cause unpredictable results. In addition, do not use DoEvents if other applications could possibly interact with your procedure in unforeseen ways during the time you have yielded control.

 

[gemma-the-husky]

if you have a continuous form, focused on one row, and click another row, a number of events fire in respect of the original row, as any edits are saved automatically

the first event that then fires in respect of the new row is the current event

often you need to think about what you are trying to do, in terms of the sequence of events.

this does mean, that after you delete a record, a different record then becomes the current record, and you then get a current event firing.

maybe you could have the delete button set a flag (boolean), that causes the current event to close at a certain point, rather than execute normal

ie this sort of thing

sub currentevent
if previousdeleteflagset then
  presviousedeleteflagset=false
  exit sub
end if
 
... otherwise operate normally
...
....
end sub