locked
Modal Form refusing to be modal RRS feed

  • Question

  • Hi,

    In Access 2010, I have a form I open from another form which adds a new record to a table and then refreshes a combo on the old form once control goes back to it (unless the user clicked cancel).  The form I'm opening flashes up but refuses to be modal, so control immediately reverts to the old form which closes it.  I've used this technique heaps of times and it's always worked.  I can't work out  what's going on.  The only different thing about this scenario is the button that opens the second form is on a tab control.  That can't be a factor...can it?   Here's the code (tried with and without SetFocus - makes no difference):

    Private Sub cmdNewProduct_Click()
        If Not (CurrentProject.AllForms("frmNewProduct").IsLoaded) Then DoCmd.OpenForm "frmNewProduct", , , , acFormAdd
        With Forms("frmNewProduct")
            .DeliverableType = 2
            .IsProduct = True
            .Modal = True
            '.SetFocus
        End With
        'When we come back to here. if the user clicked Cancel, the form will no longer be loaded, which is how we know whether to refresh the product catalogue or not
        If CurrentProject.AllForms("frmNewProduct").IsLoaded Then
            cmbProduct.Requery 'update the combo
            cmbProduct = Forms("frmNewProduct").ProductID 'set the combo to the newly created item
            DoCmd.Close acForm, "frmNewProduct", acSaveNo 'the Ok button already saved it
        End If
    End Sub
    

    Tuesday, June 20, 2017 1:26 PM

All replies

  • Please can someone help me?  What I'm trying to do isn't rocket science - I just want to have a button open a form and then once that form is finished (either Cancel is clicked or it's filled out and OK is clicked) I then want the first form to restart and process whatever's happened.  I can do this by opening the form as a dialog, but it's Access 2010, where tabbed forms all sit in the same SDI space and I don't want to suddenly introduce dialog boxes to the mix.  Modal is supposed to do exactly what I want.  Why isn't it?
    Wednesday, June 21, 2017 5:01 PM
  • Hi Mike,

    Modal does not stop code execution. If you don't want to use acDialog, then you could try using a loop. For example:

    DoCmd.OpenForm "FormName"

    Do While CurrentProject.AllForms("FormName").IsLoaded

       DoEvents

    Loop

    (untested)

    Hope it helps...



    • Edited by .theDBguy Wednesday, June 21, 2017 5:24 PM
    Wednesday, June 21, 2017 5:23 PM
  • Opening a form as model does not halt calling code.

    However, opening a form as acDialog (dialog) will halt calling code.

    So you can use the following trick:

    lets open a prompt form

    strF = "frmGetComboName"
    docmd.OpenForm strF,acNormal,,,,acDialog

    The above code opens our form "frmGetComboName", and the waits until the user enters some data, and then hits ok. The code behind the ok button in the GetName form does NOT close the form, but does

     me.Visiable = false

    At this point the code continues (the form drops out of dialog mode). So we “assume” at this point either the user hit ok button, or closed the form (and our cancel button can also just docmd.Close the form.

    If the form is still open, then user did not cancel, and we assume he hit OK.

    So code checks if the form is still open with

    CurrentProject.AllForms(strF).IsLoaded Then
        ‘code goes here to example values
       strName = forms(strF)!ThenameField
       strSex  = fomrs(strF)!GenderField
        ok, got our data...lets close the form
       docmd.Close acForm,strF
    else
        if the form is not open, then user hit the "x", or the cancel
        button on the GetName form. Note that the cancel button on
        the GetName from simply does a docmd.close

       msgbox "user canceled"
    end if

    So model forms don’t halt calling code and never did. You have to open the form as dialog.

    You can use the above, or as suggested elsewhere in this thread you can use a "loop", but the above tends to work better.

    Regards,
    Albert D. Kallal (Access MVP)
    Edmonton, Alberta Canada

    Wednesday, June 21, 2017 8:09 PM
  • Thanks for the answers.  Albert, I did try making the form hidden with the ok button and closed with the cancel one, but I then started getting a heap of "Object Required" errors when I tried to get the data from the controls on the hidden form.

    As I said in the original thread, the code I posted seems to work every where else I have it.  I got my information on Modal from the below info, duplicated in both the online help and the MSDN pages.  If the window is disabled, then the code within it should be too right?  It clearly says no other object can have the focus but the modal form, and code modules are objects.  If this isn't true, Microsoft should make this a great deal less obtuse.

    I am grateful for the replies, and have got round the issue by calling the form with OpenArgs, and having the OK button update whichever was the calling form based upon the OpenArgs.  Clumsy, but it functions.  I really wish MS would do some development on some of the antique ways Access behaves, because it's still a widely used tool.  Some controls more applicable to the type of things used today would be good too!  Rant over!

    • Proposed as answer by Chenchen Li Monday, June 26, 2017 8:20 AM
    Wednesday, June 21, 2017 11:47 PM
  • Disabling a window (which you are not doing) is not necessary going to disable the code. So this concept is VERY different then the code that calls + opens the form. So regardless of some context here, hiding a form is not related to disabling code. And saying a form is disabled or can't have focus is not the same as halting code or disabling code in that form (they are two separate ideas and concepts).

    More important, it is the calling code that you attempting and wanting to wait anyway (so even if we did hide or disable the form we just opened, the “calling” form that did the open still not going to wait or be disabled anyway.

    Remember we don’t hide the calling form, or disable it in anyway. That form will simply open another form and WAIT. But the form + code that launched that form ONLY waits if the form just opened is dialog (model will not do the truck).

    The key concept here is that the “calling” form (and code) is not going to be disabled in any fashion – and we hide the 2nd form to allow the calling code to continue.

    And hiding that form we just opened is not going to affect our form + code that opened the form. And because some form can’t have focus certainly does not suggest or prevent code from running.

    A better term then “disable” is to “hide” the form. Hiding a form does not suggest nor imply that code in that form cannot or will not run.

    At the end of the day, you simply opening a form as acDialog.

    The model setting of the form will not change nor effect this issue and process. (and it never did in the past).

    So in regards to a form having or allowed focus? Again, a different issue in regards to code running and halting. Because some form has (or has not) the focus has little bearing on code being able to run code or not.

    And we not really talking about code running or not, or disabling code. We talking about code that “waits” for the form launched, and then that code continues to run after that form is closed. So disabling code as opposed to code waiting again is a VERY different concept and idea.

    So one might disable a form, but that’s not necessary going to halt or prevent code in that form running. And as I pointed out, in this context “hiding” or “visible = false” is different then disabling a form anyway.

    So in the past, opening a form as model never did halt or stop or disable code in other forms and that includes the form that just launched the model form.

    However, when form code opens another form as dialog then most certainly that halts the calling code. That code will wait until you close the form, or do a simple act of setting the form visible = false which in turn kicks the form out of dialog mode.

    At that point the calling code can then examine the values in that form and then close it.

    This effect is identical to that of using an msgbox command in VBA. The user has to hit “ok” for the code to continue. I would not state that the code is “disabled”, but better to simply state the VBA code is waiting for the user to hit ok.

    And launching a dialog form is EXACTLY the same effect as a msgbox command. The VBA the code will wait until the user closes that form (or as noted sets the form me.Visiable = false).

    Of course if you don’t need to “examine” the values in that second opended dialog form, then you don’t need to use the me.Visible = false trick. You can simply have the ok button in that second form do a close.

    So at no point do you really make the form “disabled”. However if you want the docmd.OpenForm command to wait just like the msgbox command, then you have to open that form as “dialog”.

    The confusing arises here that many don’t distinguish between a model form in Access and a dialog form (they are VERY different in how they behave).

    Regards,
    Albert D. Kallal (Access MVP)
    Edmonton, Alberta Canada

    Thursday, June 22, 2017 12:17 AM
  • Hello Mike,

    If your issue has been resolved, I suggest you mark helpful post or your solution as answer to close this thread.

    Besides, if you have any ideas about improving Access, I would suggest you submit your feedback on Access UserVoice:

    https://access.uservoice.com/

    Regards,

    Celeste 


    MSDN Community Support
    Please remember to click "Mark as Answer" the responses that resolved your issue, and to click "Unmark as Answer" if not. This can be beneficial to other community members reading this thread. If you have any compliments or complaints to MSDN Support, feel free to contact MSDNFSF@microsoft.com.

    Monday, June 26, 2017 8:22 AM