Openform in 'Dialog' seems not to work. Processing in the call routine continues.

[corrie]

Here is the copied

Private Sub DRAcc_DblClick(Cancel As Integer)
DoCmd.Close acForm, "SelectAccount", acSaveNo
DoCmd.OpenForm "SelectAccount", acFormDS, , , acFormReadOnly, acDialog, "DrAcc"
Beep
DRAName = DLookup("AccName", "AccountChart", "AccNumber = '" & DRAcc & "'")
Let DRCTL = DLookup("AccControlled", "AccountChart", "AccNumber = '" & DRAcc & "'")


DRAmount.SetFocus


End Sub

Now the way I understand it (if one can understand stuff at age 66 that is), is that when the [DoCmd.OpenForm "SelectAccount", acFormDS, , , acFormReadOnly, acDialog, "DrAcc"] executes, the called form "SelectAccount" should open as a popup, and execution of the rest of the code should hold back until the called form is closed.

However, in my effort, the form opens as it should, but processing continues (I hear the beep), which also causes a problem as the rest of the code (DRAmount.SetFocus) fails as it is only once the called process is reacted on, that I have the required details.

Have I got my story wrong or is the code just not right? The code above is exactly as it appears in my calling form's module. The called form just allocates the selected account number to the calling form. It is just a case of the calling process continuing when I thought it won't. (That is why I added the beep in the calling code sequence).

Will be great to get this resolved - thanks.

[ItsMe]

The acDialog should be working as you expect. The one thing that stands out to me is ...

DoCmd.Close acForm, "SelectAccount", acSaveNo

If the form you are closing is the one where your code is executing, this line may be trumping the acDialog.

Also, acSaveNo is a design time command and it is rarely, if ever, used. I suggest leaving it off.

[pbaldy]

Another thought is to check for code running in the open or load events of SelectAccount. Your code looks correct to me.

[corrie]

The code closes the form that is being opened again directly after that. It is the form being called, and not the one in which the code is run. I actually added that to see if it is not a case of the form already being open from a previous call.. so the error was there even BEFORE I added that.

[June7]

acDialog has never failed for me.

Don't quite follow your last post corrie.

[pbaldy]

I'll get out of the way.

[corrie]

The called form displays a datasheet showing a list of account numbers and names... there is no actions on opening or loading.
In that form, the only code is activated when the user dbl-clicks on the account number he wants.

Option Compare Database


Private Sub AccNumber_DblClick(Cancel As Integer)
If OpenArgs = "Dracc" Then
    Let [Forms]![JournalEntry]![DRAcc] = AccNumber
    
    Let [Forms]![JournalEntry]![DRAName] = DLookup("AccName", "AccountChart", "ACCNumber = [Forms]![JournalEntry]![DRAcc]")
    


    
    
End If


If OpenArgs = "Cracc" Then
    Let [Forms]![JournalEntry]![CRAcc] = AccNumber
    Let [Forms]![JournalEntry]![CRAName] = DLookup("AccName", "AccountChart", "ACCNumber = [Forms]![JournalEntry]![CRAcc]")
End If


DoCmd.Close acForm, "SelectAccount", acSaveNo


End Sub

That is the total of code in the called form.

It actually works - but only after an error appears when the form is opened (from the other code first shown) - perfectly.

Some things get me stunned - this is one of them.

[ItsMe]

The code closes the form that is being opened again directly after that...

I see that, now. Perhaps you can go to form SelectAccount and open it in Design View. I suggest setting the Modal property to = Yes.

If that does not help, place the code you want to run in a separate procedure within the initial form's module. Something like ...

Public Sub MyNewSub()
DRAName = DLookup("AccName", "AccountChart", "AccNumber = '" & DRAcc & "'")
Let DRCTL = DLookup("AccControlled", "AccountChart", "AccNumber = '" & DRAcc & "'")

DRAmount.SetFocus
End Sub

Then, in the pop-up form's Unload event, call the sub you just built.

Forms!FormName.MyNewSub

[June7]

What error? What is its exact message? I don't see it mentioned in earlier posts.

If you want to provide db for analysis, follow instructions at bottom of my post.

[corrie]

I have used it often (kind of) and it always works fine for me too. This time is different though!

[corrie]

The form is actually quite simple - and the called form (SelectAccount) is intended to be used in conjunction with other procedures too - what gets me though, is the fact that the modality appears not to be working.
I need to resolve this as I have more places where the exact same situation, using the same 'SelectAccount' form is to be used.
Thanks for your input - it might be the way I should change my thinking, but for now I just don't want to change to a new style! The problem is that the 'beep' should only be audible when the called form is closed. The rest of the system relating to a rather wide application, is not the problem right now.

[June7]

Did you see post 9?

[ItsMe]

what gets me though, is the fact that the modality appears not to be working.

Code can override most properties set while in design view of a Form Object. However, I do not see how acdialog or any other argument provided would conflict and create the symptoms you described.

Perhaps there is corruption. I have battled corruption issues with form objects. The symptoms, although not the same symptoms you describe here, had me focused on an OpenForm with acdialog line. I recreated the form, carefully copying stuff over. I did the compile thing. I did the compact and repair thing. In the end, I triumphed.

[corrie]

I mentioned the error in my original post and explained it as best I can. It relates to a statement AFTER the original modal opening of the form 'SelectAccount'.
It says: Run-time error 2110 - 'Moerkampkoffie can't move the focus to the control DRAccout'

(Moerkampkoffie is the name of my database - we roast coffee, and my third language is English - (MoerKampKoffie means 'grainbrewed camping coffee')
If I can't come right, I will certainly make use of your offer to send the database - or part of it anyway - for analysis.

In access, when I select the 'debug' option on the error popup, it takes me to the relevant line which is AFTER the call, and the 'called' form is still open. I select the [END] option, then all works fine.

Thanks so far anyway - and please forgive my weak command of the English language and Access terminology.

[June7]

Usually helps to provide exact message. The message references DRAccout but the code reference DRAmount. DRAmount is on the called form? Why do you need to explicitly set focus? Why not let focus go to control that has TabOrder 0?