Combo box to change record not triggering the On_Current event

[Seth Schrock]

I'm just curious if this is normal. I have a combobox on a form (in the title section) that I use to go to a specific record in the form. It uses the DoCmd.SearchFor Record method. I just discovered that using the combobox to go to a record doesn't trigger the On_Current event of the form. From what I remember, it should. In this particular case it doesn't matter as all the On_Current event does is call a sub so I can just call the sub from the After_Update event of the combobox.

I also have a textbox that allows me to type in a value and it uses the Me.Recordset.Fi ndFirst method to find the record. However, it triggers the On_Current event of the form. Is the difference just in the method of going to the record?

[NeoPa]

Seth:
Is the difference just in the method of going to the record?

I would think so Seth. What does the documentation say for each approach in your version?

[Seth Schrock]

In the Access 2010 online documentation, it doesn't say anything about triggering events. Again, I feel like I have even used the DoCmd.SearchFor Record method and had it trigger the On_Current event of the form. I'll have to look through all of my databases and see if I can find out if my memory is serving me correctly. At least it doesn't seem to be common knowledge that it doesn't work.

[NeoPa]

I checked in my 2003 docs and found nothing at all for DoCmd.SearchFor Record() (probably because it was introduced later I'm thinking), and nothing for Me.Recordset.Fi ndFirst() that pertained to which events were triggered. Not helpful I know.

I suggest you do your own investigation (testing) and see what makes best sense to use.

[zmbd]

Known bug:
Allen Brown's Bug List
[ctrl][F]
"SearchForRecor d"
[enter]

My suspicion is that the search doesn't actually change the focus of the record set to the located record; however, I haven't tested this hypothesis as I typically don't do alot with the on_current event

[Seth Schrock]

That seems to be it Z. I happen to only have one record for testing purposes and as the bug states: "Access 2007 does not fire the Current event of a form after a SearchForRecord , if the first record matches the criteria." So this is what is happening and evidently Access 2010 hasn't fixed the bug either.

When I get to work tomorrow, I will try adding another record and try navigating to the second record.

[NeoPa]

Why would that be considered a bug? If the record has not moved as a result of the action I fail to see why anyone would expect the Form_Current event to fire. This was not explained in the original question Seth. Moving between records is when the Form_Current event should fire. If that doesn't happen then what would cause anyone to believe the event would fire?

[Seth Schrock]

I would go to a new record and then move to the existing record. In this exact situation, the DoCmd.SearchFor Record method doesn't trigger the On_Current event but the .FindFirst does. So obviously there is a record change going from a new record to the only record in the form's recordset. The reason I mentioned that I mentioned that there was only one record was to show that when I move to a record, it has to be the first record in the recordset.

[NeoPa]

That was good testing. Unfortunately the wording used (both here and in the linked article) fails to make it clear that the current record before the action is anything other than the first record itself. I must admit I was particularly surprised that Allen Browne's article left the position unclear. He's a bit of a start and has provided so many helpful bits of information for so many people that I can hardly complain. Just surprised is all.

In the case as it's now clear, that is an issue (bug) of course. I guess it's starting the action by moving to the first record, then determining whether to fire the event from that point on, which is logically incorrect.

PS. In the circumstances I'll set the Best Answer for you.

[zmbd]

Seth,
Not that I think there's any difference here to be found; however, I was remiss in not asking you to post at least the VBA using the SearchForRecord . Would you please do so? I've a few thoughts in mind and it would nice to start at the same point.

[z{20130112@1856 CST:Edit:}]
I've been trying to recreate this using fairly simple form; however, it appears that in V2010 the "bug" has been fixed. However, I've only been able to do a simple test due to current responsibilitie s :)
[/z{20130112@1856 CST:Edit:}]

[Seth Schrock]

I will post it on Monday when I get to work. I can also send you a copy of the database (in v2010) if you want. It only has sample data in it so it would be relatively simple to send it.

[zmbd]

I would think the code should be enough a.t.p.i.t. (At this point in time).

[NeoPa]

Z:
it appears that in V2010 the "bug" has been fixed. However, I've only been able to do a simple test due to current responsibilitie s

Understood, and interesting. I now understand that it is a bona fide bug, given Seth's explanation in post #8. I'm very curious to follow this thread.

NB. As I found no reference to this feature (DoCmd.SearchFor Record) in A2003 at all, and Z reports it as {probably} fixed in A2010, are we talking about an A2007 specific bug here?

[Seth Schrock]

The bug is listed as being in A2007, but I'm using A2010 and am still experiencing the bug. Not sure why Z isn't being able to reproduce the error unless I'm doing something wrong with my code.

@Z I did have to look up what ATPIT meant ;). Thanks though for clarifying.

[zmbd]

Sorry,
Was in a hurry between things...
My Father and Late-Stepfather are both military; thus, I was raised with a lot of little acronyms and I forget to translate them sometimes.



For the simple database:
MS Access 2010/Office 2010- enterprise - all current patches and service packs installed;
I have one table with my generic people list.
One Query based on that table.
One form bound to the query.
Header is title and labels above controls in the detail section
Detail section has text controls bound to the record set.
Footer section
Two command buttons.
Unbound text controls that mirror the bound controls in number
One command button has code that uses the form's record set and the findfirst method.
Second command button uses the SearchForRecord method using just the defaults.
I've hard coded the "where" string for both buttons to search for a specific first name in the record set.
The on_current event is coded to fill the unbound text boxes in the footer with the currently selected record values.

Onload, the on_current fires and the first record's values are entered into the unbound text boxes.
Clicking on either button sets the focus in the form to the hardcoded lookup - the unbound text boxes update as one would expect. Select some other record (the unbound text boxes update as expected) and then click either button and the same happens.

When things settle down a tad I will add a text box to allow user entry and see what happens.