none
Design Question: Modal forms vs. Non-modal

    Question

  • I've been struck with the issue of deciding on when to open a form with acDialog and when NOT to. For instance, if a list of customers is presented and one is chosen, then should the detail form be set to dialog mode (modal) or should I permit users to just keep opening up as many detail forms as they want ? Then they might even attempt to open the same customer detail form twice (I think Access will throw an error though).

    If changes are made that affect the parent form (the list form), then that might need to be requeried if new customers were added or existing customers were deleted. I have to do that on every OnFocus for the parent form unless I have a sophisticated mechanism in place to have interform communication via Tempvars, etc.

    Can anyone comment on this issue ? It seems to me that as a developer, we should not allow the user to get "bollixed up" with too many open forms anyway. Maybe 3 forms open as the max ?

    Sunday, December 19, 2010 9:20 PM

Answers

  • "Syswizard" wrote in message news:13b6d77b-cef3-4b89-86c8-74bd471f6944@communitybridge.codeplex.com...

    I've been struck with the issue of deciding on when to open a form with acDialog and when NOT to. For instance, if a list of customers is presented and one is chosen, then should the detail form be set to dialog mode (modal) or should I permit users to just keep opening up as many detail forms as they want ? Then they might even attempt to open the same customer detail form twice (I think Access will throw an error though).

    If changes are made that affect the parent form (the list form), then that might need to be requeried if new customers were added or existing customers were deleted. I have to do that on every OnFocus for the parent form unless I have a sophisticated mechanism in place to have interform communication via Tempvars, etc.

    Can anyone comment on this issue ? It seems to me that as a developer, we should not allow the user to get "bollixed up" with too many open forms anyway. Maybe 3 forms open as the max ?

    I have a lot of comments here, but the first thing you really have to get straight, and I'm going to repeat this very strongly again:
     
    There is a spectacular mount Everest huge massive difference between a dialog form and a modal form.
     
    I would say in most of my rich UI applications, approximately 80% or even more of my forms are modal. The reason for this As a developer you'll often need to control the flow of which forms are used, and if the user has traversed through two or three forms to get the particular spot or location within the application, I don't want them circumventing that position in the Application and going to some previous forms until they completed the particular task in the existing form that they are being presented with. So, to return to the previous form, they have to close the current one.
     
    In fact without using modal forms, you really as a developer cannot correctly build an application and control what the user does in any sensible fashion all. If I'm hiring as access developer, one of my questions is to explain the differences between the four types of forms in access, and when you should use them. (and the WHEN part is the big one!)
     
    A dialog form is a very different animal, and hear is some text from a previous post of mine on this issue:
     
    ===============
    Just like we often use the term access and jet interchangeably, we should not always do that.
     
    Modal forms are considerably different than dialog forms when speaking of access forms. When you launch a dialog form, the calling code halts and waits for that dialog form to be dismissed. Another interesting aspect of a dialog form is that you cannot move the focus outside of that dialog form. This means that you can�??t even use a custom ribbon or menu bar. So the focus can not be moved out of that form that prompts the user. In effect this form is the SAME scenario and behavior as the built in message box command or inputbox command.
     
    You cannot move focus out of that message box, or dialog form until you dismiss it. And you can not even move focus to the access interface or built in menus or ribbons.
     
    This means if you design an application around dialog forms, you CAN NOT USE custom ribbons or menu bars.
     
    For controlling user flow within an application, in most cases the best choice is a modal form. In the case of a modal form, the calling code (openform command) is not halted when you launch the form. So, code that launches the form CAN ALSO RUN additional code in that calling code to set values up in that form just opened. eg:
     
    docmd.OpenFrom "frmCustomers"
    forms("frmCustomers")!todayDate = date()
     
    A modal form also allows the focus to move out of the form and into a ribbon or menu bar.
     
    What this means is, that a dialog form is rather draconian in terms of how it controls the application. Any dialog form launched, means that you can�??t move the focus out of it.
     
    Contrast the above behavior of a modal form, in which the calling code is NOT halted, and in which you�??re free to move the focus out of the form into a custom menu bar or custom ribbon.
     
    What the above means is, for the most part you want to avoid dialog forms unless you want the calling code to halt, or are your building some type of custom message box that must be dismissed and you don't want focus to be able to be moved out of that form, even into the ribbon. And of course if you're building an application with any kind of custom ribbon or menu bars, then again you can't use dialog forms, can you ? As I said, there's some pretty big spectacular differences here, and is simply out of the blue throwing out the term dialog forms, and modal forms is going to cause some serious confusing as what the intentions are here for the developers reading this.
     
    This same goes for a popup form. (again a REALLY DIFFERENT kind of form!). A popup form can be displayed on top of all other forms, but does not have to receive the focus. So for wizard type, or an information box that you want to float on top of the forms DURING data entry is what a popup form is for. So, all the while the user continues to enter data in those OTHER forms, that popup form can float and remain on top, and display all kinds of help type of information, but does not need to receive the focus.
     
    So we're talking about a form that floats and displays on top of everything else, but does not yet have to have the cursor or even receive the focus inside of that form.  Needless to say out of the blue simply selecting a form as popup is an another great way of instantly messing up your whole application and your whole ability to control what form has the focus and what form is to stay on top. We've often seem some posters here who've accidentally set a form as pop up (or simply by intention and not knowing what the feature is for), and then they become like a dog chasing their tail and begin to set form after form as popup as they try to reassert their desire to control the next form being launched as going on top of everything else when in fact those non popup forms for the most part will all of a sudden NOT naturally open as expected on top of the previous forms. (the popup forms will remain on top of those form opened!).
     
    So in closing.
     
    A dialog form:
     
    A dialog form halts the calling code, must always be dismissed, and does not allow you to use custom menu bars or built in ones. These dialog forms also mean you give up use of the ribbon (the focus cannot move out of the dialog box).
     
     
    A modal form:
     
    A modal form allows focus to move out into the ribbon or menu area, but you can�??t move focus to other forms. Call code is NOT halted when you launch a modal form. You can also have multiple copies of the SAME form open.
     
     
    A popup form:
     
    A popup form can be displayed on top of all the forms, but does not have to receive the focus. So for informational type of display while the user continues to do data entry into an existing form is when you use a popup form.
     
    A regular form:
    A regular form generally has no focus restrictions.
     
    Also, you can NOT have multiple instances of a dialog form, but you can for regular, modal, and I believe so for popup forms. So, if your design is to allow multiple instances of the SAME form to be opened, then dialog is NOT choice you have for that type of form.
     
    In some designs, it is preferable to allow multiple instances of the same form to be launched and in use at the same time.  A typical use scenario would be a complex data entry form that's halfway done, the phone rings and you have to deal with an different customer but you need the SAME data entry form again. So, as a developer you can implement a design that would allow the user to minimize the current form, and launch and utilize another copy of the exact same form and this would allow you to deal with different multiple customers at the same time without having to complete and close down the current form due to you only being half way done with that form, but we also need to use this same for another task or customer.
     
    So the types of forms and choices we have in Access are all VERY different and that includes modal and dialog. And each type of form has great use for different scenarios.
     
    So choosing the correct type of form in access is a big part of the development process.
     
    --
    Albert D. Kallal (Access MVP)
    Edmonton, Alberta Canada
    Pleasenospam_kallal@msn.com
    • Marked as answer by Syswizard Monday, December 20, 2010 5:43 PM
    Monday, December 20, 2010 6:02 AM

All replies

  • This might provide some background info.
    http://www.members.shaw.ca/AlbertKallal/Dialog/Index.html
    Sunday, December 19, 2010 11:00 PM
  • Hello Syswizard.

    I guess you mean the master/detail form with multiple forms that the form wizard creates, Is far as I remember, the form wizard creates code that uses "DoCmd.OpenForm..." which opens a "default instance" of the details form. This way, there can not be multiple instances of the details form on the screen. To be able to see multiple instances of the same form on the screen, you will have to create the instances via code (...= New Form_...) and also write code that manages the instances (for an unknown number of  instances to "live" side by side, there has to be something like an array that holds all references. When the last reference to an instanciated form is deleted, the form disappears.

    Personnaly, I don't like the code the wizard generates, because it lacks some functionality like adding a new record in the details form (the linked field of the master is not retrieved for the new detail record as a foreigh key). But I think, the user should not be able to create more than one instance of a dateils record.

    When the 2nd form really was a dialog (no data editing but "settings") then I would open it via DoCmd with acDialog. A requery of the master form could be done right after the OpenForm method call. When opening a data related form, I prefer not using the acDialog switch, because then there is no default search functionality in the dialog/details form.
    The "communication" with the master form could ba achieved by the call of a custim method of the master (public sub or function) or by simply requerying it from the details form. Also, events could be used as a way of intercommunication between the forms, but I think, that could be difficoult to handle if multiple instances were allowed. If only one instance was allowed, the master form could store a reference to the details form in a "WithEvents" variable that traps special events of the details form like the Close event to requery comboboxes and so on (Remarks: For this to work, the details form has to have at least a dummy event procedure for the close event).

    --
    Kind regards,
    WOlfgang

    Sunday, December 19, 2010 11:09 PM
  • "Syswizard" wrote in message news:13b6d77b-cef3-4b89-86c8-74bd471f6944@communitybridge.codeplex.com...

    I've been struck with the issue of deciding on when to open a form with acDialog and when NOT to. For instance, if a list of customers is presented and one is chosen, then should the detail form be set to dialog mode (modal) or should I permit users to just keep opening up as many detail forms as they want ? Then they might even attempt to open the same customer detail form twice (I think Access will throw an error though).

    If changes are made that affect the parent form (the list form), then that might need to be requeried if new customers were added or existing customers were deleted. I have to do that on every OnFocus for the parent form unless I have a sophisticated mechanism in place to have interform communication via Tempvars, etc.

    Can anyone comment on this issue ? It seems to me that as a developer, we should not allow the user to get "bollixed up" with too many open forms anyway. Maybe 3 forms open as the max ?

    I have a lot of comments here, but the first thing you really have to get straight, and I'm going to repeat this very strongly again:
     
    There is a spectacular mount Everest huge massive difference between a dialog form and a modal form.
     
    I would say in most of my rich UI applications, approximately 80% or even more of my forms are modal. The reason for this As a developer you'll often need to control the flow of which forms are used, and if the user has traversed through two or three forms to get the particular spot or location within the application, I don't want them circumventing that position in the Application and going to some previous forms until they completed the particular task in the existing form that they are being presented with. So, to return to the previous form, they have to close the current one.
     
    In fact without using modal forms, you really as a developer cannot correctly build an application and control what the user does in any sensible fashion all. If I'm hiring as access developer, one of my questions is to explain the differences between the four types of forms in access, and when you should use them. (and the WHEN part is the big one!)
     
    A dialog form is a very different animal, and hear is some text from a previous post of mine on this issue:
     
    ===============
    Just like we often use the term access and jet interchangeably, we should not always do that.
     
    Modal forms are considerably different than dialog forms when speaking of access forms. When you launch a dialog form, the calling code halts and waits for that dialog form to be dismissed. Another interesting aspect of a dialog form is that you cannot move the focus outside of that dialog form. This means that you can�??t even use a custom ribbon or menu bar. So the focus can not be moved out of that form that prompts the user. In effect this form is the SAME scenario and behavior as the built in message box command or inputbox command.
     
    You cannot move focus out of that message box, or dialog form until you dismiss it. And you can not even move focus to the access interface or built in menus or ribbons.
     
    This means if you design an application around dialog forms, you CAN NOT USE custom ribbons or menu bars.
     
    For controlling user flow within an application, in most cases the best choice is a modal form. In the case of a modal form, the calling code (openform command) is not halted when you launch the form. So, code that launches the form CAN ALSO RUN additional code in that calling code to set values up in that form just opened. eg:
     
    docmd.OpenFrom "frmCustomers"
    forms("frmCustomers")!todayDate = date()
     
    A modal form also allows the focus to move out of the form and into a ribbon or menu bar.
     
    What this means is, that a dialog form is rather draconian in terms of how it controls the application. Any dialog form launched, means that you can�??t move the focus out of it.
     
    Contrast the above behavior of a modal form, in which the calling code is NOT halted, and in which you�??re free to move the focus out of the form into a custom menu bar or custom ribbon.
     
    What the above means is, for the most part you want to avoid dialog forms unless you want the calling code to halt, or are your building some type of custom message box that must be dismissed and you don't want focus to be able to be moved out of that form, even into the ribbon. And of course if you're building an application with any kind of custom ribbon or menu bars, then again you can't use dialog forms, can you ? As I said, there's some pretty big spectacular differences here, and is simply out of the blue throwing out the term dialog forms, and modal forms is going to cause some serious confusing as what the intentions are here for the developers reading this.
     
    This same goes for a popup form. (again a REALLY DIFFERENT kind of form!). A popup form can be displayed on top of all other forms, but does not have to receive the focus. So for wizard type, or an information box that you want to float on top of the forms DURING data entry is what a popup form is for. So, all the while the user continues to enter data in those OTHER forms, that popup form can float and remain on top, and display all kinds of help type of information, but does not need to receive the focus.
     
    So we're talking about a form that floats and displays on top of everything else, but does not yet have to have the cursor or even receive the focus inside of that form.  Needless to say out of the blue simply selecting a form as popup is an another great way of instantly messing up your whole application and your whole ability to control what form has the focus and what form is to stay on top. We've often seem some posters here who've accidentally set a form as pop up (or simply by intention and not knowing what the feature is for), and then they become like a dog chasing their tail and begin to set form after form as popup as they try to reassert their desire to control the next form being launched as going on top of everything else when in fact those non popup forms for the most part will all of a sudden NOT naturally open as expected on top of the previous forms. (the popup forms will remain on top of those form opened!).
     
    So in closing.
     
    A dialog form:
     
    A dialog form halts the calling code, must always be dismissed, and does not allow you to use custom menu bars or built in ones. These dialog forms also mean you give up use of the ribbon (the focus cannot move out of the dialog box).
     
     
    A modal form:
     
    A modal form allows focus to move out into the ribbon or menu area, but you can�??t move focus to other forms. Call code is NOT halted when you launch a modal form. You can also have multiple copies of the SAME form open.
     
     
    A popup form:
     
    A popup form can be displayed on top of all the forms, but does not have to receive the focus. So for informational type of display while the user continues to do data entry into an existing form is when you use a popup form.
     
    A regular form:
    A regular form generally has no focus restrictions.
     
    Also, you can NOT have multiple instances of a dialog form, but you can for regular, modal, and I believe so for popup forms. So, if your design is to allow multiple instances of the SAME form to be opened, then dialog is NOT choice you have for that type of form.
     
    In some designs, it is preferable to allow multiple instances of the same form to be launched and in use at the same time.  A typical use scenario would be a complex data entry form that's halfway done, the phone rings and you have to deal with an different customer but you need the SAME data entry form again. So, as a developer you can implement a design that would allow the user to minimize the current form, and launch and utilize another copy of the exact same form and this would allow you to deal with different multiple customers at the same time without having to complete and close down the current form due to you only being half way done with that form, but we also need to use this same for another task or customer.
     
    So the types of forms and choices we have in Access are all VERY different and that includes modal and dialog. And each type of form has great use for different scenarios.
     
    So choosing the correct type of form in access is a big part of the development process.
     
    --
    Albert D. Kallal (Access MVP)
    Edmonton, Alberta Canada
    Pleasenospam_kallal@msn.com
    • Marked as answer by Syswizard Monday, December 20, 2010 5:43 PM
    Monday, December 20, 2010 6:02 AM
  • Indeed, if you want to open twice the same form to compare, side by side, say, the details for two (or more) different clients, you will need to use  ... =new Form_...  syntax, in VBA code, since DoCmd will just open a single default one if you specify the same FormName, but with other filter/where:

    DoCmd.OpenForm "Form1", WhereCondition:= "Id =2"
    DoCmd.OpenForm "Form1", WhereCondition:= "Id =3"

    opens a single form Form1, not two.

    (Note that a user may also try to open your application TWICE to open the same form, with different criteria, side by side, without requiring any additionnal coding for you. But again, if you want to open the form twice, you can, in one application, using New Form_xxx  syntax.)

    As a general rule, use acDialog if the logic implies it (such as when in need to add a new client, in table Clients, to be done BEFORE further processing of adding a whole record in table Orders implying this new client). Otherwise, your application should be built to not allow what you don't want: as example, with menu driven application, if menu1 (in form1) allows to open a form (form2) , then, to avoid someone to even try to open another form, from form1, then form1 can become invisible when form2 is open and, on closing form2, form1 can become visible again.

    Monday, December 20, 2010 4:55 PM
    Moderator
  • I truly appreciate the feedback and the lesson Albert.

    Thanks much Vanderghast for that tidbit on multiple open forms of the same name....very excellent ideas.

    Monday, December 20, 2010 5:44 PM
  • Well Albert, after further modifications and review using Modal=True instead of acDialog (Model=true, popup=true), I've had a lot to reconsider:

    I used to be able to control the return of the called form from the host form.
    This is no longer the case because I've had to move the code from the host to the called form.
    And that posed a huge problem: duplicate code...now must be generalized. Now the code is called from many detail forms.

    Here's what I was attempting to do: Show a list form in datasheet view. Select an item from the list and call any number of detail forms. Then return to that form once the detail form that was called is closed and place the datasheet row key field into focus. Also, I'm check to see if new record was entered, or an old one was deleted. In the case of the latter, I then set the focus to the first record in the datasheet view.

    Thursday, December 23, 2010 4:35 PM