Code only works when stepping through code line by line

[postman]

Any idea why code would work as intended when setting a breakpoint and stepping through it line by line, but won't work correctly at run-time?

The code is too much to post, so I hope this summary of the setup will suffice:

There are 3 forms:

• MainForm
• recordForm (subform on MainForm)
• dlgForm (pop-up form)

A button on MainForm opens dlgForm. (dlgForm is declared as an object variable.)

If "OK" is clicked on dlgForm, a custom event is triggered in that form's Close event which switches the recordForm's recordsource to the table. The focus is (supposed to be) shifted to a control in recordForm and the following line is called to create a new record in the table:

DoCmd.RunCommand acCmdRecordsGoToNew

Everything hinges on the focus being shifted to the subform.

When the code runs, the dlgForm retains the focus despite the "setfocus" commands in the event code and the "new record" command throws an error that the command is not available.

If I set a breakpoint in the dlgForm's Close event and step through the code line by line, the focus shifts as it should and all works well.

Sorry for the long post. Any ideas would be much appreciated!

[Megalog]

Since dlgform is a popup, maybe the focus is being forced to stay on that form until it's closed. On the button's click event, try putting the form's close event first, and then follow it with all the supporting code for MainForm.

[NeoPa]

It's hard to work on one of these remotely, but this sort of thing is down to timing issues, or specifics of rule-bending in order to provide debugging.

Something like the dlgForm being available while debugging because the debugger couldn't work otherwise, yet when running full speed this is closed by that point. I'm guessing to a certain extent as I have not enough contact to see the whole picture clearly.

One way to fix this is to avoid any possibility of conflict. Perhaps the dlgForm code could invoke a procedure within one of the other forms' modules instead. Whichever seems the easiest or more appropriate to you.

Let us know how you get on.

[NeoPa]

I've just seen Megalog's response, and it occurs to me that it may be this simpler explanation (I always seem to find a complex answer when easier ones are more obvious).

[ADezii]

Any idea why code would work as intended when setting a breakpoint and stepping through it line by line, but won't work correctly at run-time?

The code is too much to post, so I hope this summary of the setup will suffice:

There are 3 forms:

• MainForm
• recordForm (subform on MainForm)
• dlgForm (pop-up form)

A button on MainForm opens dlgForm. (dlgForm is declared as an object variable.)

If "OK" is clicked on dlgForm, a custom event is triggered in that form's Close event which switches the recordForm's recordsource to the table. The focus is (supposed to be) shifted to a control in recordForm and the following line is called to create a new record in the table:

DoCmd.RunCommand acCmdRecordsGoToNew

Everything hinges on the focus being shifted to the subform.

When the code runs, the dlgForm retains the focus despite the "setfocus" commands in the event code and the "new record" command throws an error that the command is not available.

If I set a breakpoint in the dlgForm's Close event and step through the code line by line, the focus shifts as it should and all works well.

Sorry for the long post. Any ideas would be much appreciated!

As far as the Focus issue goes, transfer the Focus as a 2-Step process fully qualifying the Paths as in:

Forms!MainForm![recordForm].SetFocus
Forms!MainForm![recordForm].Form![<Control on recordForm>].SetFocus

Let us know if this works out.

[postman]

As far as the Focus issue goes, transfer the Focus as a 2-Step process fully qualifying the Paths as in:

Forms!MainForm![recordForm].SetFocus
Forms!MainForm![recordForm].Form![<Control on recordForm>].SetFocus

Let us know if this works out.

I tried this and get the same issue--the dlgForm continues to retain the focus.

Here are a few more details I extracted that I hope may clarify the issue. As mentioned, the dialog form is declared as a variable in the MainForm module:

Private WithEvents newDlg As Form_dlgForm

The button on MainForm that opens the dialog uses this code to do so:

Set newDlg = New Form_dlgForm
newDlg.Visible = True

On the dlgForm, the "Form_Close " event contains code that raises a custom event:

Public Event CreateNewItem(itmType As String, newItm As Integer, itmID As Long)
Private Sub Form_Close()
    RaiseEvent CreateNewItem(itmType, Me.Frame4, Nz(newItemList, -1))
End Sub

In the MainForm module, the custom event has the code to peform the previously mentioned actions on the recordForm subform:

Private Sub newDlg_CreateNewItem(itmType As String, newItm As Integer, itmID As Long)
Form_MainForm.[recordForm_SubformControl].SetFocus 
Form_recordForm.[controlOnSubform].SetFocus 
Form_recordForm.RecordSource = "myTable"
DoCmd.RunCommand acCmdRecordsGoToNew
End sub

[FishVal]

What about Megalog's hypothesis - could dlgForm.Modal property be True?

[postman]

What about Megalog's hypothesis - could dlgForm.Modal property be True?

No, I double-checked and the Modal property is not set to True.

In regards to Megalog's hypothesis, I agree--but isn't that how it's already setup? The custom event is raised in dlgForm's Close event.

[FishVal]

What happens if you get references this way?

Private Sub newDlg_CreateNewItem(itmType As String, newItm As Integer, itmID As Long)
With Me.[recordForm_SubformControl]
    .SetFocus 
    With .Form
        ![controlOnSubform].SetFocus 
        .RecordSource = "myTable"
    End With
End With
DoCmd.RunCommand acCmdRecordsGoToNew
End sub

What happens if RecordSource is not changed or changed before setting focus on subform's control?

[postman]

What happens if you get references this way?

Private Sub newDlg_CreateNewItem(itmType As String, newItm As Integer, itmID As Long)
With Me.[recordForm_SubformControl]
    .SetFocus 
    With .Form
        ![controlOnSubform].SetFocus 
        .RecordSource = "myTable"
    End With
End With
DoCmd.RunCommand acCmdRecordsGoToNew
End sub

What happens if RecordSource is not changed or changed before setting focus on subform's control?

I tried that and the RecordSource suggestion and it's the same thing--will only work correctly when stepping through line-by-line.

[FishVal]

Ok.

Seems it is a synchronization issue.
I suggest you to run form timer and do all the job in Form_Timer handler.

Private Sub newDlg_CreateNewItem(itmType As String, newItm As Integer, itmID As Long)
    Me.TimerInterval = 1
End sub

Private Sub Form_Timer()
    Me.TimerInterval = 0
    Me.[recordForm_SubformControl].SetFocus
    DoCmd.RunCommand acCmdRecordsGoToNew
End Sub

[postman]

Resolved

Ok.

Seems it is a synchronization issue.
I suggest you to run form timer and do all the job in Form_Timer handler.

Private Sub newDlg_CreateNewItem(itmType As String, newItm As Integer, itmID As Long)
    Me.TimerInterval = 1
End sub

Private Sub Form_Timer()
    Me.TimerInterval = 0
    Me.[recordForm_SubformControl].SetFocus
    DoCmd.RunCommand acCmdRecordsGoToNew
End Sub

SUCCESS! THANK YOU!

So, it needed a millisecond to complete the closing of the dlgForm before proceding through the next set of procedures?

[FishVal]

SUCCESS! THANK YOU!

You are welcome.

So, it needed a millisecond to complete the closing of the dlgForm before proceding through the next set of procedures?

I don't think so.
Access rarely do things asynchronously, so 1ms form timer means ring after 1ms and after all operations (e.g. in your case any code after RaiseEvent and, maybe, destroying form object) needed to be done have been completed.

[ADezii]

Really nice work FishVal. I already put in a request to Mary and NeoPa for a substantial wage increase for you! (LOL)!

[NeoPa]

We're impressed too ADezii.

This will result in an immediate doubling of your wages Fish :)