Which Button triggered the afterdate of a textbox

[sneuberg]

In our database the afterupdate for the textbox which maintains the primary key calls a subroutine which upon detecting an existing record gives the user the option of going to that record or not. We put this in the afterupdate to give the user immediate feedback. Unfortunately this doesn’t work exactly the way we want if the user updates the textbox to an existing record and then clicks on a button; let’s say the Delete Record button for example (We realized this would be weird user behavior, but we need to cover it). The afterupdate is trigger first so the user is asked if he wants to go to the existing record. Because of this possible record change we want to abort the delete and we have found we can do this just by setting focus on something other than the textbox that lost focus. So this is ok, but we haven’t figured out a way to let the user know that his delete operation was intentionally canceled. If there were just someway of detecting that the action that triggered the afterupdate was the clicking of the delete button. Any ideas?

[ItsMe]

I do not allow Users to have access to the intrinsic tools in Access. The delete tool is an example of a built in tool that the User would not have access to in one of my apps. I find it easier to write code to replace the intrinsic tools than to write code to chase down what the User did via the intrinsic tools.

[sneuberg]

I do not allow Users to have access to the intrinsic tools in Access. The delete tool is an example of a built in tool that the User would not have access to in one of my apps. I find it easier to write code to replace the intrinsic tools than to write code to chase down what the User did via the intrinsic tools.

The delete button was just given as an example and it's not an intrinsic tool, but a command button which runs code that warns the user and then executes SQL to delete the record. A difference button example would be Save/Add New. We abort this operation too and would like to tell the user why.

[burrina]

Why not then after using the OnGotFocusEvent for the TextBox and use MsgBox "Your Update Has Been Cancelled"

[sneuberg]

Why not then after using the OnGotFocusEvent for the TextBox and use MsgBox "Your Update Has Been Cancelled"

It is not always the case that we need to give the user a message. If the user tabs out of the primary key textbox and triggers the afterupdate we don't need to tell the user anything extra. It's just when the user triggers the afterupdate by clicking on some button that we'd like to them know why the buttons function was cancelled, preferably on the the message box that asks them if they want to go to the existing record.

As an update to my original post I've discovery that not only does setting focus cancel the buttons operation, but it seems that going to a different record does the same thing (we are using the filter property to change records). I was beginning to think that perhaps I could set some global flag in the afterupdate and then make a decision based on that flag in the buttons code to execute the code or give the user a message that the operation was cancel. But since the buttons code doesn't run after a record change even that solution has disappeared into the event sewer.

[burrina]

One final suggestion. Make a label visible depending on criteria. Otherwise, Good Luck With Your Project.

[Missinglinq]

...In our database the afterupdate for the textbox which maintains the primary key calls a subroutine which upon detecting an existing record gives the user the option of going to that record or not...

This type of code belongs in the BeforeUpdate event of the Textbox, not the AfterUpdate event, then use Cancel = True to prevent the creation of the New Record. Typical code for this kind of thing would be

Private Sub Field1_BeforeUpdate(Cancel As Integer)
 If DCount("Field1", "Domain", "Field1 = " & Me.Field1) > 0 Then
  Resp = MsgBox("This Value Already Exists! Please Enter New Value")
  Cancel = True
 End If
End Sub

To be honest, I'm a little fuzzy as to your process, here, but this change may serve your needs.

Linq ;0)>