RPC Server is Unavailable in Windows 8 App running in Windows Server 2012

 

Problem: This was an annoying problem – but I guess I have never encountered a non-annoying problem: Was working with a Windows App Store app on my Windows Server 2012 dev server. The app contained some media – mp3 and mp4 files – stuff that required audio. Whenever the app would attempt to stream one of these files into Windows Media Player (unimportant side note: Was using the Microsoft Media Platform Player Framework), the app would crash with the error “RPC Server is unavailable’.

Solution: After ensuring the Remote Procedure Call service was running (that would have been WAY too easy), and checking the event logs – which was a dead end – I noticed that the Windows Audio service was NOT running – and set to manual startup.  Starting the Windows Audio service resolved the issue.

I get why the Windows Audio service is not set for automatic start by default for Windows Server 2012 – so when it comes to this particular problem, I feel no anger towards Microsoft or the Windows Server team. In fact, I really like Windows Server 2012 so far – and still even hold Windows Server 2008 in high regard!

MetroPivot Web Part released on Codeplex

Finally got off my ass and published a side project I had around for a while. Get it on CodePlex at http://metropivotwebpart.codeplex.com/.

What is it? If you are familiar with the EasyTabs web part, it is basically the same thing with a lot more style: Drop it in a Web Part zone, and it will ‘wrap’ all of the web parts in that zone into a fancy metro-styled pivot control. Check out the video demo:

metropivot demo from Chad Schroeder on Vimeo.

People Picker Plus for SharePoint 2010

A no-touch replacement for the horrid built in people picker control

Finally finished it up! Get it on CodePlex: http://peoplepickerplus.codeplex.com/

The SharePoint 2010 People Picker has always caused problems for me. Either by not working in what it deems to be 'down level' browsers (Firefox and Chrome), showing red X's instead of user images, random script errors, or totally failing within an HTML5 doctype, the list of crap I have taken from it is extensive. So I finally had enough and developed a solution to bury it with a much more user-friendly and sensible component. Oh yeah, and it works the same under all BICA (Browsers I Care About), like IE 9+, Chrome, Firefox, and even poor little Safari. The major features of it include:

• Activate 'n Go! Activate the site collection scoped feature and be done - all people pickers will be replaced within the site.
• Cross-browser! Unlike the built in entity picker, which devolves into a textarea for non-IE browsers, the People Picker Plus works the same way no matter what browser is being used. Also, it is HTML5 friendly.
• Autocomplete Searches!As the user types, search results are displayed, and even grouped by User, SharePoint group, and Security Group.
• User Image ProxyUser images located on mysites usually cause an annoying extra authentication prompt within the default people picker dialog. Your users won't miss this!
• Decent UI!The UI for the built in people picker is awful. Especially for 'down level' browsers like Chrome and Firefox. The UI for the People Picker Plus is better than awful! Plus it is touch-friendly, should your users be crazy enough to try to use SharePoint on a tablet.

Feedback is greatly appreciated, especially of the constructive kind. If you feel the need to hit me with anything negative, it better contain humor.

HTML5 + SharePoint People Picker: I give up!

The SharePoint 2010 people picker is a piece of crap. Plain and simple. I have not had a chance to check out what 2013 has to offer for a people picker control – honestly I am a little scared to. I just know that the people picker breaks all the time in IE under normal circumstances, and when you try to use an HTML5 master page on your SharePoint site, it gets even worse. There are some ways to try to fix it that people have put out there (see here: http://social.msdn.microsoft.com/Forums/da/sharepoint2010general/thread/8c83010e-d351-48ba-bd1e-1ffb0641ec03) but but I have not come across a 100% solution to fix IE yet that results in a working HTML5 page.

This is the funny part: When the browser is not IE – something superior like Chrome or Firefox – the people picker is functional. It is ugly – showing login names rather than display names – but that is a small price to pay for having it be functional. Plus it has always been ugly. So I thought – ‘Hey, what if I could make the code think it was using a different browser so the people picker can work…’ And here is how I did it:

Add this JavaScript to the bottom of your master page. (If you do not have a custom master page, you are out of luck – since most of the people pickers can be found on layouts pages.)

if (typeof (PreferContentEditableDiv) == "function") {
    //force downlevel people picker because HTML5 + IE makes people picker more terrible than usual
    PreferContentEditableDiv = _PreferContentEditableDiv;
    $("div.ms-inputuserfield").css("display", "none");
    $("textarea.ms-inputuserfield").css({"display": "inline", "position":"static"});
}

jQuery, AJAX, and Aggressive iOS Caching

This was the situation: A jQuery Mobile app was using jQuery AJAX requests to get JSON data from the server. Nothing crazy – except for maybe the server was a SharePoint server. I know – running one of those IS pretty crazy.

The requests from a typical browser worked as expected. No issues. With the ‘cache’ flag turned off, the server logs were showing each request come in when it was expected. Then came the iPad + iPhone testing. Initially all looked great. Except after the first request, subsequent requests never made it back to the server. WTH?

Turns out iOS does not honor the ‘cache’ flag in the jQuery AJAX object. In case you are not familiar with this, here is what a typical jQuery AJAX request looks like:

$.ajax({
            url: ws_url,
            type: "POST",
            data: JSON.stringify(data),
            dataType: 'json',
            contentType: "application/json; charset=utf-8",
            async: true,
            cache: false, //to cache or not to cache
            success: function (data) {
                //yes
            },
            error: function (jqXHR, exception, errorThrown) {
               //no
            }
        });

Caching is good and all, but most of the time you need to control it, like if you had a refresh button. This is usually done by changing the ‘cache’ flag to false. To account for the iOS family, you must also add the cache-control header and set it to ‘no-cache’ – which looks like this:

$.ajax({
            url: ws_url,
            type: "POST",
            data: JSON.stringify(data),
            dataType: 'json',
            contentType: "application/json; charset=utf-8",
            async: true,
            cache: false,
            headers: { "cache-control": "no-cache" },
            success: function (data) {
                //yes
            },
            error: function (jqXHR, exception, errorThrown) {
                //no
            }
        });

Hope this saves someone some time.

SharePoint 2010: Easy Dynamic Resize of Dialogs

Some situations require asynchronously loaded data. When this data is within a SP dialog, the dialog will have ugly scrollbars. You could try to guess at the size of the dialog ahead of time when you open it, but that would be what people call ‘lame’. What you need is to dynamically resize the dialog once the async load is complete.

Holy Crap: When I searched for this I found some long, half-baked solutions that had more holes than a Toyota pickup truck in the Middle East. Some examples: An MSDN forum post and Some Dude’s Blog – both long, and (sorry fellas) – kind of crappy.

Solution turned out to be kind of easy – here is the pattern:

JavaScript:

function AutosizeDialog(){
    //resize dialog if we are in one
    var dlg = SP.UI.ModalDialog.get_childDialog();
    if (dlg != null) {
        dlg.autoSize();
    }
}

function LoadPageData(){
    //PSEUDOCODE jquery ajax
    $.ajax({
            url: < web service providing the data >,
            /* other ajax options */
            async: true,
            cache: false,
            success: function (data) {
                /* load data into element(s) */
                AutosizeDialog();
            },
            error: function (err) {
                /* be good and handle errors */
            }
        });
}

Explanation: The function “LoadPageData” is your function that loads data into your page dynamically. Maybe it loads it from a web service using SPServices, or jQuery ajax (exampled above). Maybe it is just via a client function generating HTML dynamically. Or maybe it’s something really cool I don’t even know about. Whatever the case may be, the important part is that after the HTML has been set, a call to the “AutosizeDialog” function is made.  That is where the easy magic happens – all within SharePoint native client methods.

Important note: This is all WITHIN the dialog content. Some examples you see out there try to do resizing from the place where the dialog is created. Usually using some kind of whacked-out timer delay. Avoid this.

Pretty simple after all – no need for any extra junk.

Update #1

So it quickly became obvious that something else is needed after the dialog is resized: The window then should be repositioned so the dialog is nice and centered. Again – no need for any JavaScript craziness, and especially no need for long winded explanation – here is the updated version of AutoSizeDialog:

function AutosizeDialog() {
    //resize dialog if we are in one
    var dlg = typeof(SP.UI.ModalDialog.get_childDialog) == "function" ? SP.UI.ModalDialog.get_childDialog() : null;
    if (dlg != null) {
        dlg.autoSize();
        var dlgWin = $(".ms-dlgContent", window.parent.document);
        dlgWin.css({ top: ($(window.top).height() / 2 - dlgWin.height() / 2) + "px", left: $(window.top).width() / 2 - dlgWin.width() / 2 });
    }
}

Just two lines to cover resizing – probably could even be reduced to one. Also added an extra check to for the SP.UI.ModalDialog load state.

SharePoint Saturday Virginia Beach 2012

SharePoint Saturday 2012 Virginia Beach was great, like all of the SPSaturday’s in Virginia Beach before it.

I took this photo at the beginning of the kick off – a few minutes later, the seats in front of me were filled and people were standing along the walls.

Below is my HTML5 presentation. I welcome any and all feedback.

Bringing HTML5 alive in SharePoint

View more presentations from Chad Schroeder.