Current Event handling (1 Viewer)

[kirkm]

What is the correct way to handle Form_Current event?

I'm finding it runs many times while I am initialising various controls in my startup Form.
The only way I've found to stop it is Me.OnCurrent = "" in Form load. (And later Forms!Form1.OnCurrent = "[Event Procedure]")
But this prevents Form Current running at all, until I move to another record. So I have my own Current event to call as I want.
But I feel there's something wrong and I should be able to use the native Access functions.

Startup Form

Private Sub Form_Load()
    Dim Yr As String
    Dim Path As String
    Path = BrowseFolder("Enter Path To Check")
    If Path > "" Then
            Yr = YrFromPath(Path)
            If Yr > "" Then
                    DoCmd.OpenForm "Form1", acNormal
                    Forms!Form1.RecordSource = "Select * from qryBB Where Year = '" & Yr & "';"
                    Forms!Form1.txtPrefix.ControlSource = "Prefix"
                    Forms!Form1.lblPath.Caption = Path
                    DoCmd.Close acForm, "frmStartup"
                    Forms!Form1.OnCurrent = "[Event Procedure]"
                    Forms!Form1.MyCurrent
                Else
                    MsgBox "No Year found in " & Path
            End If
        Else
            MsgBox "No Path Supplied"
    End If
End Sub

Main Form

Private Sub Form_Current()
Debug.Print "Current"
  MyCurrent
End Sub


Private Sub Form_Load()
    Me.OnCurrent = ""
End Sub


Public Sub MyCurrent()
Debug.Print "MyCurrent"
  Dim files As Variant
    ReDim files(0)
    Me.txtPrefix.ControlSource = "Prefix"
    If FolderExists(Me.lblPath.Caption) = True Then
        files = gFindFiles(Me.lblPath.Caption, Me!Prefix & "*.jpg", False)
    End If
    Me.lblImageCount.Caption = "Images Found: " & UBound(files)
End Sub

 

[arnelgp]

we do not know what Form1 is doing. maybe it is Taking the Focus out
from the Original form thats why the current event is not firing.
maybe when you close Form1, the current event will fire.

 

[The_Doc_Man]

But this prevents Form Current running at all, until I move to another record.

I'm finding it runs many times while I am initialising various controls in my startup Form.

The meaning of the Form_Current is that a bound form synchronizes with a record from the recordset to which it is bound. All bound controls will have values corresponding to the .ControlSource settings for each underlying .Recordsource field. This will happen once per record-related event such as saving, deleting, or navigating.

The _Current event SHOULD fire once per navigation (moving to another record, including a new record if you create one) and SHOULD fire once per saving an updated record since after the update or navigation is complete, the form and underlying record ARE synchronized again. For most cases, I could see a given record going through two _Current events - the step that navigates to the (new or existing) record and the step that saves (updates) it.

For you to see multiple _Current events beyond what I described, you must be EITHER modifying the main form's .Recordsource OR forcing a save operation on the record OR forcing a record navigation. It is VERY RARE to use a Form_Load event to load a form's .Recordsource because normally you just load that source statically. It is not clear to me what you are trying to do in overview. I can see the instructions but don't see how they would lead to what you have described. Which means we aren't seeing everything.

 

[Pat Hartman]

The current event for the main form runs twice when the form has subforms. If it is running more times, then as Doc said, your code is causing it.

You will find that you have a smoother operation if you do NOT automate forms this way. Either use the WHERE option of the OpenForm method to control the recordset OR pass in the SQL String or use a saved querydef with arguments that pull data from the controlling form.

What do you think this instruction is doing?

Me.OnCurrent = ""

 

[The_Doc_Man]

Thanks, Pat. Forgot about the effect of sub-forms on the main.

@kirkm - now that Pat has reminded me about sub-forms having that effect I can see that part of the problem is you are doing a lot in the _Current routine that maybe is overkill. I'll focus on one that jumped out at me.

In your Form_Load routine, you have this line.

Forms!Form1.txtPrefix.ControlSource = "Prefix"

In your MyPrefix routine you have THIS line, but in Form_Load immediately after you load Form1 you call MyPrefix to do other things including this.

Me.txtPrefix.ControlSource = "Prefix"

So my first question is, when is the control source for txtPrefix ever NOT "prefix" ?

There is another, far more subtle situation, though.

It is not clear which form is running the Form_Load routine you showed in post #1 (maybe your startup form that you mentioned?), but it activates Form1 and then eventually tries to call MyPrefix which appears to be a routine in another class module (from that syntax). At least you DID declare that to be Public.

All well and good, except that the context involved is still that of the form running the Form_Load routine because you are invoking a subroutine. Therefore, the Me.txtPrefix.ControlSource action will look for a control called txtPrefix in that startup form(?) context. That is because ME still refers to the caller's context. When you have that _Load routine perform the .ControlSource update and then do it again in MyPrefix, you are potentially touching two different controls.

Stated another way, when Access activates an event routine, it IS a subroutine call... but Access does some things outside the call to establish a context before your code gets to run. When YOU make the subroutine call, you don't know how to change the context setup. So you simply call the subroutine from the context you are in.

I checked the VBA Language Specification (2014) for Call semantics (implicit or explicit). Putting a prefix on the call (Forms.Form1, for example) provides a location of where to find something but doesn't necessarily specify a context. Therefore, I suspect this set of code routines that you showed us doesn't do exactly what you think it does.