.NET FOLLOWER

    How to create/open a Modal Dialog Window (along with the passing parameters into it) is shown in the post SharePoint: How to pass parameters into a Modal Dialog Window and then access them. This post, in turn, will be devoted to closing the Modal Dialog Window.

Modal Dialog Window is based on IFrame element

As you probably know, Modal Dialog Windows are implemented through IFrame elements. So, when saying “open a web page in a Modal Dialog Window” we mean to load another Html document into an IFrame element of the current Html document. Let’s call the page, which hosts the IFrame element, a Parent-page and the page loaded into the IFrame – a Child-page. From the Child-page the IFrame element containing it can be reached by means of the window.frameElement DOM-object.

Methods to close Modal Dialog Window

To close a Modal Dialog Window we can employ the methods shown below. Note that the methods become accessible through the window.frameElement after the dialog has been opened/created, in other words, SP Dialog framework extends the window.frameElement object by adding these custom methods.

• SP.UI.ModalDialog.commonModalDialogClose(DialogResult dialogResult, Object returnVal)
• window.frameElement.commonModalDialogClose(DialogResult dialogResult, Object returnVal)
• window.frameElement.commitPopup(Object returnVal)
• window.frameElement.cancelPopUp()
• Summary

SP.UI.ModalDialog.commonModalDialogClose

This method allows to close the current (the most recently opened) Modal Dialog Window, passing a desirable DialogResult and a return value into the dialogReturnValueCallback method. This method is mostly intended to be called from the Parent-page. Below is a sample of possible use. Let’s assume that within the Parent-page we have two JavaScript functions, OpenChildDialog and CloseChildDialog, and a Html link, which opens the dialog and sets up the delayed closing of it. The functions:

function OpenChildDialog() {
  var opt = {
    url : 'childPage.aspx',
 
    dialogReturnValueCallback:
      function (res, retVal) {
        alert(retVal);
      }
  };
  SP.UI.ModalDialog.showModalDialog(opt);
}
function CloseChildDialog() {
  //SP.UI.ModalDialog.commonModalDialogClose(SP.UI.DialogResult.OK, 'Closed with OK result');
  SP.UI.ModalDialog.commonModalDialogClose(SP.UI.DialogResult.cancel,'Cancelled'); 
}

The link:

<a href="#" onclick="OpenChildDialog(); setTimeout(function(){ CloseChildDialog(); }, 10000); return false;">
Open dialog
</a>

So, clicking on the link you open the dialog, which will be closed automatically in 10 seconds unless you close it manually before.

window.frameElement.commonModalDialogClose

Technically, it’s the same commonModalDialogClose function, but accessible through the window.frameElement object. Unlike the previous one the given function is intended to be called from within the Child-page (opened in the dialog). The main advantage of the window.frameElement.commonModalDialogClose is that it can be invoked from within a SharePoint-independent page, which knows nothing about SP Dialog framework and its js-files. Before showing an example, let’s take a look at the SP.UI.DialogResult enumeration, which is situated in the SP.UI.Dialog.js file:

SP.UI.DialogResult.prototype = {
    invalid: -1, 
    cancel : 0, 
    OK     : 1
}

Use of SP.UI.DialogResult inside the SharePoint-independent page will cause getting of ‘SP’ is undefined error message. So, we have to use the real values of SP.UI.DialogResult as the enumeration apparently will be undefined. So, below is an example of use. Let’s assume that to open the dialog we use the same OpenChildDialog method listed above and, somewhere within the Child-page, we have two Html links to close the dialog with OK or cancel as the result. The links:

<a href="#" onclick="window.frameElement.commonModalDialogClose(1 /*OK*/, 'Closed with OK result'); return false;">
Commit
</a>
<a href="#" onclick="window.frameElement.commonModalDialogClose(0 /*cancel*/, 'Cancelled'); return false;">
Cancel
</a>

window.frameElement.commitPopup

The given function closes the dialog and passes SP.UI.DialogResult.OK as the result. It also allows to pass a return value into the dialogReturnValueCallback method. Like the previous one, window.frameElement.commitPopup is intended to be called from within the Child-page, which may be SharePoint-independent. Traditionally, an example implies that the dialog is opened by the OpenChildDialog method and contains a Html link:

<a href="#" onclick="window.frameElement.commitPopup('Closed with OK result'); return false;">
Commit
</a>

Another good example of use of window.frameElement.commitPopup is demonstrated in the article – SharePoint: SPLongOperation inside a Modal Dialog Window.

window.frameElement.cancelPopUp

The window.frameElement.cancelPopUp closes the dialog as well. However, as opposite to commitPopup, it returns the SP.UI.DialogResult.cancel as the dialog result and doesn’t allow to pass a return value. It should be called from within the Child-page, which may be SharePoint-independent. The opened dialog can be closed, for example, by the Html link, which is placed within the Child-page and defined as the following:

<a href="#" onclick="window.frameElement.cancelPopUp(); return false;">
Cancel
</a>

Summary

Let’s take a look at a summary table below. The SharePointless column indicates whether the appropriate function can be used from within a SharePoint-independent page. The Intended to be placed within column shows where the appropriate function should be put in, in either Parent– or Child-pages. Note that there are no strict rules where the functions must be used, all of them, in some conditions, can be used on any pages.

    In one of my posts I wrote about using SPLongOperation. When a lengthy operation has been accomplished the usual behavior of the SPLongOperation is to redirect user to another web page. In SharePoint 2010, however, the web page containing long operation could be opened in a Modal Dialog Window. In this case, instead of redirection, we often need to close the dialog right after the long operation is completed.

SPLongOperation.EndScript method

Fortunately, the SPLongOperation class provides us with a new useful method, EndScript, which notifies server that the operation has been completed and sends a specified JavaScript into the user browser. A typical use is presented below:

using (SPLongOperation operation = new SPLongOperation(this.Page))
{ 
    operation.LeadingHTML  = "Long operation";
    operation.TrailingHTML = "Please wait while the long operation is in progress";
 
    operation.Begin();
 
    // the code of the lengthy operation
    ...
 
    // check if the current page is opened in dialog
    if(SPContext.Current.IsPopUI)
        // signal that the lengthy operation is completed and 
        // send a script to close the current dialog
        operation.EndScript("window.frameElement.commitPopup();");
    else
        // signal that the lengthy operation is completed and 
        // redirect to another page
        operation.End("anotherPage.aspx");
}

The window.frameElement.commitPopup() script allows to close the dialog and pass SP.UI.DialogResult.OK as the result. The SPContext.Current.IsPopUI flag indicates if the current page is going to be opened in dialog and should be rendered in an appropriate way.

Wrapper around SPLongOperation

In the same old post I demonstrated a handy wrapper around SPLongOperation. Taking into account the dealing with dialogs, the updated version of the wrapper looks as follows:

public class SPLongOperationExecutionParams
{
    public string LeadingHtml  { get; set; }
    public string TrailingHtml { get; set; }
    public string RedirectUrl  { get; set; }
    public bool   CloseDialog  { get; set; }
}

public static void DoInSPLongOperationContext(SPLongOperationExecutionParams executionParams, Action action)
{
    if (HttpContext.Current.CurrentHandler is Page)
    {
        using (SPLongOperation operation = new SPLongOperation(HttpContext.Current.CurrentHandler as Page))
        {
            operation.LeadingHTML  = !string.IsNullOrEmpty(executionParams.LeadingHtml)  ? executionParams.LeadingHtml  : "Long operation";
            operation.TrailingHTML = !string.IsNullOrEmpty(executionParams.TrailingHtml) ? executionParams.TrailingHtml : "Please wait while the long operation is in progress";

            operation.Begin();

            if (action != null)
                action();

            try
            {
                if (executionParams.CloseDialog)
                    operation.EndScript("try { window.frameElement.commitPopup(); } catch (e) {}");
                else
                    operation.End(executionParams.RedirectUrl, SPRedirectFlags.DoNotEndResponse | SPRedirectFlags.Trusted, HttpContext.Current, "");
            }
            catch (ThreadAbortException)
            {
                // This exception is thrown because the SPLongOperation.End
                // calls a Response.End internally
            }
        }
    }
    else
        throw new ApplicationException("Couldn't find a host page!");
}

Below is an example of how to use it:

void startLongOperationButton_Click(object sender, EventArgs e)
{
    SPLongOperationExecutionParams executionParams = new SPLongOperationExecutionParams() 
    { 
        LeadingHtml  = "Creation of a new list item", 
        TrailingHtml = "Please wait while the item is being created", 
        CloseDialog  = SPContext.Current.IsPopUI, // if the page is in a dialog, the latter will be closed
        RedirectUrl  = "anotherPage.aspx" // if it's not a dialog, user will be redirected to that page
    };

    DoInSPLongOperationContext(executionParams, delegate()
    {
        // the code of the lengthy operation
        Thread.Sleep(5000);
    });
}

Passing parameters into a Modal Dialog Window

Opening a web page in a Modal Dialog Window we can pass parameters to it through the args property of dialog options. A typical JavaScript might look like

function OpenDialog() {
  var opt = {
    url     : 'somePage.aspx',
    autoSize: true,
 
    /* additional parameters */
    args: { arg1: 'The second argument is ', arg2: 12345 },
 
    dialogReturnValueCallback:
      function (res, retVal) {
        if (res === SP.UI.DialogResult.OK) { /* do something */ }
        else { /* do something else */ }
      }
  };
  SP.UI.ModalDialog.showModalDialog(opt);
}

Now let’s take a look how these parameters can be accessed from within the Parent-page and the page opened in the dialog.

Accessing the arguments from within the page opened in the dialog

In general case, when opening a SharePoint-based page, the passed arguments could be reached using a script similar to the following:

function DoSomethingWithArgs() {
  var passedArgs = SP.UI.ModalDialog.get_childDialog().get_args(); /* get access to the passed parameters */
  alert(passedArgs.arg1 + passedArgs.arg2);
}

The key method here is SP.UI.ModalDialog.get_childDialog, which allows to get the current dialog, or, to be more precise, the current SP.UI.Dialog object. The retrieved object, in turn, exposes the get_args method to access the passed parameters.

A possible use of the DoSomethingWithArgs function from the sample above is

<a href="#"
  onclick="ExecuteOrDelayUntilScriptLoaded(DoSomethingWithArgs, 'sp.ui.dialog.js'); return false;">
Show me the passed arguments
</a>

In case the web page opened in the dialog knows nothing about SharePoint and doesn’t include appropriate SharePoint JavaScript files, use the following version of the code:

function DoSomethingWithArgs() {
  var passedArgs = window.frameElement.dialogArgs; /* get access to the passed parameters */
  alert(passedArgs.arg1 + passedArgs.arg2);
}

Where the dialogArgs as a property of the window.frameElement object is provided by SP Dialog framework and returns the passed arguments.

Assuming the SharePoint‘s ExecuteOrDelayUntilScriptLoaded function isn’t available as well, the possible use of the DoSomethingWithArgs is quite straightforward:

<a href="#" onclick="DoSomethingWithArgs(); return false;">
Show me the passed arguments
</a>

All other conditions being equal, I recommend the approach with the window.frameElement object as it works always and doesn’t require the page in the dialog to be bound to SharePoint somehow.

Accessing the passed arguments from within the Parent-page

The Parent-page is a place where we define parameters and pass them to the dialog. So, the most direct way is to store the required values into some variable(s) to access them later. Another way is to rely on Dialog framework and use the code already mentioned in the previous section, namely

//...
var passedArgs = SP.UI.ModalDialog.get_childDialog().get_args();
//...

The more interesting case, however, is to access the passed arguments inside the dialogReturnValueCallback function. The listing below contains an example of one of such dialogReturnValueCallback definitions:

function OpenDialog() {
  var opt = {
    url     : 'somePage.aspx',
    autoSize: true,

    /* additional parameters */
    args: { arg1: 'The second argument is ', arg2: 12345 }, 

    dialogReturnValueCallback:
      function (res, retVal) {
        if (res === SP.UI.DialogResult.OK) {                    
          var passedArgs = this.get_args(); /* get access to the passed parameters */
          alert(passedArgs.arg1 + passedArgs.arg2);
        }
      }
  };
  SP.UI.ModalDialog.showModalDialog(opt);
}

The dialogReturnValueCallback function will be called in the context of the SP.UI.Dialog object associated with the current Modal Dialog Window. Therefore, inside the function the passed arguments can be accessed using this-keyword.

A possible use of the OpenDialog is shown below:

<a href="#" 
  onclick="ExecuteOrDelayUntilScriptLoaded(OpenDialog, 'sp.ui.dialog.js'); return false;">
Open Modal Dialog Window
</a>

ps There is a quite detailed article about dealing with Dialogs in SharePoint 2010. So, read to learn more about Dialog framework.

    In SharePoint 2010 by default a list item is opened in a Modal Dialog Window. The dialog adjusts its size depending on the size of the contained content and provides users with buttons to maximize and close itself. So, I was asked to maximize the dialog when opening some list items.

Creating and Initializing of a Modal Dialog Window

The JavaScript responsible for the dialog rendering is in the SP.UI.Dialog.js file (usually located in C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\TEMPLATE\LAYOUTS). Clicking on a link-title, for example, in a list view leads to creating and displaying a new Modal Dialog Window in a manner similar to the following:

var options = SP.UI.$create_DialogOptions();

options.url           = 'display-page corresponding to the current list item';
options.title         = 'list item title';
options.allowMaximize = true;
options.showClose     = true;

// possible option, but it's not used in the place in question
//options.showMaximized = true;

var modalDialog = SP.UI.ModalDialog.showModalDialog(options);

The commented line demonstrates one of the possible settings, showMaximized, which apparently does exactly what we need. So, it would be a good solution if we had control under creation of the dialog. Unfortunately, we don’t have. Modifying scripts in SharePoint system js-files runs counter to all known “best practices”, therefore I don’t even consider it. Another possible way is override the client-side OnClick-events of the link-title fields everywhere (in list views, web parts and so on) so that your own script would create and display the dialog in a required manner. Obviously, it’s a very time-consuming solution. Moreover, every time when creating a list view, web part or something else you always have to keep in mind the possible need to rewrite their OnClick-events. In my opinion the only acceptable approach is allow a web page itself to maximize the dialog window it’s placed in.

Script to Maximize a Modal Dialog Window

For that, first of all, we need to have a JavaScript to maximize the current dialog. As SP.UI.Dialog.js doesn’t provide a function/method intended for use outside, we have to consume undocumented internal functions. A suitable script is described in the blog post – “How to maximize a Modal Dialog in JavaScript?“. With slight changes the JavaScript looks like the following

function _maximizeWindow() {
    var currentDialog = SP.UI.ModalDialog.get_childDialog();
    if (currentDialog != null && !currentDialog.$S_0)
        currentDialog.$z();    
    }
    ExecuteOrDelayUntilScriptLoaded(_maximizeWindow, 'sp.ui.dialog.js');

_maximizeWindow gets the current dialog window instance and tries to maximize it if it hasn’t been done before. ExecuteOrDelayUntilScriptLoaded, in turn, is applied to ensure the _maximizeWindow is called after the sp.ui.dialog.js has been completely loaded.

Script Applying

Having the script, we can insert it into the end of a web page to be maximized. It could be done through SharePoint Designer or by modifying a physical aspx-file defined as a display/new/edit form for a list or a content type. However, I decided to add the script dynamically in a page’s code-behind. So, the resultant code is shown below:

using System;
using System.Web.UI;
using Microsoft.SharePoint;

//...

public class DisplayListItem : Page
{
    protected override void OnLoad(EventArgs e)
    {
        base.OnLoad(e);
        if(!IsPostBack)
            AddMaximizeWindowScript();
    }

    //...

    protected virtual void AddMaximizeWindowScript()
    {
        if (SPContext.Current.IsPopUI)
        {
            const string scriptKey = "MaxWinwScript";
            if (!ClientScript.IsClientScriptBlockRegistered(GetType(), scriptKey))
            {
                const string jsScript =
                    @"function _maximizeWindow() {
                        var currentDialog = SP.UI.ModalDialog.get_childDialog();
                        if (currentDialog != null && !currentDialog.$S_0)
                            currentDialog.$z();    
                        }
                        ExecuteOrDelayUntilScriptLoaded(_maximizeWindow, 'sp.ui.dialog.js');";

                ClientScript.RegisterClientScriptBlock(GetType(), scriptKey, jsScript, true);
            }
        }
    }
    
    //...
}

You may ask why I use RegisterClientScriptBlock instead of RegisterStartupScript or window.onload, or jQuery‘s $(document).ready (the latest two arise on client side). The reason is that initially the dialog window is created with the autoSize option. So, it’s very reasonable to maximize the window as soon as possible to prevent the content’s size calculating, which apparently happens after the page has been loaded entirely.