SharePoint 2013 Chrome Control Parameters List

I had a hard time Google-Binging this information – so here is what I dug directly out of the source:

Param Name	Description
siteTitle	The title of the site.
siteUrl	The url of the site. [This is easy!]
clientTag	? Tag the page ?
appWebUrl	The current app web url.
onCssLoaded	Callback function for when chrome control is done loading. [Great naming there!]
assetId	? The app’s id in the catalog ?
appStartPage	Start page of app web. Need to test this…
rightToLeft	For those languages that go against the grain.
appTitle	Title of the app. [Back to easy street!]
appIconUrl	The url of the app icon.
appTitleIconUrl	Titles need icons too.
appHelpPageUrl	The url of your very useful help page.
appHelpPageOnClick	Use this to alert(‘No help 4 U!’)
settingsLinks	Array of links to put under the ‘options’ wheel.
language	¿Qué diablos?
bottomHeaderVisible	Hide the bottom header.
topHeaderVisible	Guessing this may hide the top header. Since chrome control does so much to everything in addition to the top header [sarcasm], I can see never using this option.

SharePoint s4-notnotdlg: The opposite of s4-notdlg

[Until I do, this is a warning about this only being tested in 2010]

So there is a CSS class in SharePoint that allows you to have content that will NOT show up in any dialog: The s4-notdlg class. Pretty easy: just add the class to your fancy branding, elements, etc. and it will be excluded when element is displayed in a SharePoint dialog.

 

But what about the opposite: Is there a class that lets you have content that will ONLY display in a dialog? No, there is not. But through the magic of CSS selectors, you can accomplish this behavior pretty easily:

Use SharePoint Modal Dialog to Prompt for Text

You need to prompt the user for some text from somewhere within a SharePoint site. How to you go about this?

1. Use the JavaScript 'window.prompt' method? Too ugly and limited style and validation options.
   
2. Incorporate a jQuery plugin that makes for easy prompting? May or may not work with SharePoint, and even then it will most likely have a UI style that is different.
   
3. Use the SharePoint dialog API to show a modal page? Close - but that means we have to create and deploy an entire ASPX or HTM page to show within the dialog. That is a lot for what boils down to a label and a text box.
   
4. Embed the script below and move on to checking on your Klout status.
   

Yeah, I like #4 too - except for the Klout part.


What this script does:

• Shows a SharePoint modal dialog and injects content and style, so it looks like the rest of your UI.
  
• Does not require you to build another page for the dialog UI.
  
• Returns the text the user entered.
  
• Validates that the user typed in something by default. You can optionally provide a maximum length or a custom validation function to use.
  
• Requires jQuery. Probably could be written to be dependency-free, but that would be many more lines of code - especially the CSS cloning part.

Using DispEx in a Link to a SharePoint Document

I needed to create a link to a document the same way SharePoint does it: using the DispEx client side function. The DispEx function performs all of the magic involved with opening an Office document directly in the appropriate Office app in a nice way, as long as you are using Internet Explorer of course. I believe it also uses ActiveX to do this, but that will be for another ran.. I mean blog post.

Searching for how to create such a link proved worthless. There are a few posts and Q&A’s on Stack Overflow out there, even at least one from one of those soon-to-be-extinct MVP’s – but they all hard coded most of the parameters for the function. It is true that the function has a plethora of parameters, but having them hard coded is not desirable – especially when the parameters are based on user-configurable settings, such as the ‘Force Checkout’ option in a document library.

 

Below is some code to create the ‘click’ script for the anchor element, gleaned via ILSpy and modified to accept an SPFile parameter. The DispEx  function (and dependencies) also require that the anchor element have an HREF attribute set to the server-relative URL of the file. In the case of an SPFile instance, this would be FIle.ServerRelativeURL.

        private string GetFileViewScript(SPFile file)
        {
            string text = SPUtility.MapToControl(SPContext.Current.Web, file.Name, string.Empty);
            string text2 = (file.Item.ParentList.DefaultItemOpen == DefaultItemOpen.Browser) ? "1" : "0";
            SPFieldLookupValue sPFieldLookupValue = file.Item["CheckedOutUserId"] as SPFieldLookupValue;
            string scriptLiteralToEncode = (sPFieldLookupValue == null) ? string.Empty : sPFieldLookupValue.LookupValue;
            string text3 = (SPContext.Current.Web.CurrentUser != null) ? SPContext.Current.Web.CurrentUser.ID.ToString(CultureInfo.InvariantCulture) : string.Empty;
            string text4 = file.Item.ParentList.ForceCheckout ? "1" : "0";

            return string.Format(CultureInfo.InvariantCulture, "return DispEx(this,event,'{0}','{1}','{2}','{3}','{4}','{5}','{6}','{7}','{8}','{9}','{10}','{11}','{12}')", new object[]
            {
                "TRUE",
                "FALSE",
                "FALSE",
                text,
                text2,
                text,
                string.Empty,
                string.Empty,
                SPHttpUtility.EcmaScriptStringLiteralEncode(scriptLiteralToEncode),
                text3,
                text4,
                (string)file.Item["IsCheckedoutToLocal"],
                (string)file.Item["PermMask"]
            });
        }

SendEmail from CurrentUser Caution in SharePoint 2010

This is a quick one I ran across, and yes: it was really annoying:

The SPUtility’s SendEmail method has several overloads. Check it out if you want to: http://msdn.microsoft.com/en-us/library/microsoft.sharepoint.utilities.sputility.sendemail(v=office.14).aspx

The most flexible overloads accept a StringDictionary. The dictionary allows us to specify any email headers we want to, most notably the ‘to’, ‘subject’, ‘cc’, and ‘from’ headers.

In the SendEmail overloads that are not taking a StringDictionary, notice there is no ‘from’ parameter. This is because the current Web Application’s outbound email address is automatically used as the ‘from’ address when using those methods.

When using on of the StringDictionary overloads, one would think leaving out the ‘from’ header would result in the same thing: the current Web Application’s outbound email address is used. This is NOT THE CASE.

What happens is that if the ‘from’ header is not in the StringDictionary or if it is null, the current user’s email address will be used as the FROM address in the email. If your email server has any type of security hardening this will result in the email being rejected since the app pool probably does not have the necessary rights to send an email on any old user’s behalf.

How to fix? Couldn’t be easier:

            ...
            //email sendin code
            StringDictionary headers = new StringDictionary();
            headers.Add("to", toAddress);
            if (!string.IsNullOrEmpty(fromAddress))
            {
                headers.Add("from", fromAddress);
            }
            else
            {
                headers.Add("from", GetFromEmailAddress(web));
            }
            headers.Add("subject", subject);
            headers.Add("content-type", "text/html");

            SPUtility.SendEmail(web, headers, body);
            ...
        
        //get the FROM email address configured for the web app
        internal static string GetFromEmailAddress(SPWeb web)
        {
            return web.Site.WebApplication.OutboundMailSenderAddress;
        }

Stay Modal, My Friends

I don’t often need to prevent a SharePoint 2010 modal dialog window from closing, but when I do I use the code below:

//step 1: check if we are in a dialog
var dlg = typeof (SP.UI.ModalDialog.get_childDialog) == "function" ? SP.UI.ModalDialog.get_childDialog() : null;

if (dlg != null && dlg.$5_0) {
    //step 2: hide close button
    dlg.$5_0.style.display = "none";
}

Then, when you want to allow the dialog to be closed again, the code is:

//step 1: check if we are in a dialog
var dlg = typeof (SP.UI.ModalDialog.get_childDialog) == "function" ? SP.UI.ModalDialog.get_childDialog() : null;

if (dlg != null && dlg.$5_0) {
    //step 2: show close button
    dlg.$5_0.style.display = "inherit";
}

SPSite.MakeFullUrl Lies To You and Me!!

Today we are complaining about this method of SPSite: MakeFullUrl

The complaint is this: In SharePoint 2010, it always returns the root web url, no matter what site collection instance it is used upon.

Here is the example: Given the following code block, what would you expect the resulting output to be when used in different site collection contexts:

Code

Response.Write(SPContext.Current.Site.MakeFullUrl("/Lists/Tasks"));

 

Test 1
Hitting the code at http://sharepoint/_layouts/test.aspx – the ROOT site collection - results in the output:

http://sharepoint/Lists/Tasks

Test 2
Hitting the code at http://sharepoint/sites/AnotherSiteCollection/_layouts/test.aspx – the AnotherSiteCollection site collection - results in the output:

http://sharepoint/Lists/Tasks

Conclusion
Since MakeFullUrl is an instance method of an SPSite object, you would think the result URL would take the SPSite into consideration. It does not, and therefore it sucks.