Don’t always assume things are what you believe them to be…

I had one of those “duh” moments today…

I had a report from a customer who was claiming that a link to a document in an automated email was broken. Since the email was generated from an InfoPath form when the form was submitted (and presumably saved also), I had my doubts. However, when I went to the library and checked for the document, it wasn’t there. No recycle bin, the submitter had Contribute access without delete…

… or so it appeared.

It turns out that the person submitting the form is one of two people who share the same name. I saw “her name” in the permission list, and assumed all was well. But when I finally noticed her picture compared to an email picture, I noticed they were two completely different people. The person who was submitting the form didn’t have Contribute access, so the email would send but the form wouldn’t save.

Note to self… never assume that everything is as you believe it to be without double-checking the obvious.

Displaying a PowerPoint slide in a Page Viewer Web Part

Bottom line… this is FAR more difficult than it needs to be… 😦

The straightforward (and intuitive) way to do it would be to create a new page and add a Page Viewer web part:20150921Image01

Next, go out to one of your document libraries, open up the PowerPoint file in browser mode, and get the URL:20150921Image02

That gives you a URL that looks somewhat like the following:

No problem, right? Actually, major problem, as it gives you the following error:20150921Image03

What you have to do instead is search the page source code to find the iframe tag. It’s within there that you’ll find the actual code you’re looking for:20150921Image04

In this case, the iframe code for my PowerPoint file is:

PowerPointFrame.aspx?PowerPointView=ReadingView&d=F4d0845e366cf4196adc344c19238f728md26da0e52012465c8dbe3c9d5cafe974m07df9f35b715495798c790767e0515a8m&source=http%3A%2F%2Fdomain%2Ecom%2Fsites%2FDuffTeamSite%2FShared%2520Documents%2FForms%2FAllItems%2Easpx” width=”100%” height=”100%” style=”position: absolute; top: 0px; left: 0px; right: 0px; bottom: 0px;” frameborder=”0″>

From that, you have to take a snippet of that code above (in bold green) and add the bold purple code below to get the following for your page URL:


Once you have that completed, you can use that URL as the address for your web page to show (in this case, your slides):20150921Image05

To get it to be a bit more visible, adjust the height and width parameters of the web part:20150921Image06

This is how I have to set up PowerPoint page viewer web parts in SharePoint 2010. I certainly hope it gets more intuitive in upcoming versions.

Comparing People Picker names to blank values? I use a BlankName field…

Much like I suggested in my Empty Date Field post, I’ve found myself starting to add EmptyName as a column to some of my lists that require comparisons (usually during workflows) to blank values. I just find it easier to know I’m going to match up exactly to what a blank people picker field will look like.

Just create a column in the list, name it something like EmptyName, and leave the default value as blank. Then use that field as the comparison value to any of your other names that you’d like to check against.

Want to compare a field against a blank date? Put a blank date in your list…

This is sort of a “why would you do that?” thing, but it’s saved me a lot of time when it comes to SharePoint Designer workflows.

I’ve always had problems trying to compare a variable in the workflow against a blank date, because every date variable wants you to populate it with the current date or some other set date. Furthermore, there’s no “Is Empty” as a comparison option.

I know you can compare the string to some magical date of 1/1/0001, but I’m always afraid I’m going to make a typo or that default date is going to change some time in the future. Instead, I prefer to let SharePoint do the work for me.

I create a list column with the name of EmptyDate and I don’t give it a default value. Therefore, when it comes time to compare dates, I already have a blank date field in the list that I can use for the comparison. Since I normally customize my list forms using InfoPath, I just choose not to put that field on the form.

I don’t have to remember any magical dates, nor do I have to worry about anyone coming behind me and messing up that value by adding leading zeros or something. It just works. 🙂

Multi-line text fields, character count limits, and scrolling… that was unexpected.

So I got this request to make a multi-line text field scroll in one of my forms. That sounded easy enough. But there seems to be a problem when you also have a line-character length set. If you set a line character limit, it greys out the ability to set it as a multi-line field.

To get around that, I decided to hack the field validation a bit. Instead of using the character limit count in the list item, I used an expression in the validation rule to check the character length and fire an error if it’s over 320 characters:


That was the magic combination to allow the text to scroll down in the field, while still limiting the number of characters allowed. Instead of just stopping at the 321st character, it fires a validation error if it goes over that length.

Not quite as clean as the character size limit field on the list item, but it works.

A list change doesn’t always trigger an InfoPath customized form refresh…

This was a strange one learned today under a bit of pressure (and a crazy idea that I thought of on my very own!)

I have a list in test that I’m keeping separate from the production list due to a ton of significant modifications that have changed/rechanged/scope-creeped over the last three months. Requests to change the “form fields” had, up to this point, just been changes to the labels in front of the fields. I didn’t worry about making the minor name tweaks in the actual list fields because I didn’t want to deviate any more than I already have from what’s in production.

That was all well and good… until the customer noticed that the column headers didn’t match the field name changes on the form. Late in the game and testing was supposed to start this afternoon, but fine… I’ll do it. I had them give me a list of the column names that absolutely needed to change, and what the field name should be. All normal stuff…

I made the changes in the list, and then went to Customize Form to pull in the changes and re-publish it. I was a bit surprised I didn’t get the warning message saying there were list changes, but I normally don’t change field names like that. I tweaked a couple of things on the form labels, re-published, and let them know I had done all the changes…

… only to find that all the list field name changes had reverted to the old names.

Suffering from insanity, I did the same thing again, expecting to get different results. And true to insanity, I got the same results. What’s worse, I wasn’t seeing a way I could change the field name on the form to get what I wanted in the list.

I sat back for a second and thought… I know the form has to refresh from the list when I add new fields to the list. How can I force a refresh, and if I can, will it grab the field name changes from the list?

“Test Field 1” to the rescue!

I added a test field to the list along with changing a couple of the field names to see if they would be refreshed in the form. The new field triggered the InfoPath form refresh, and the refresh picked up both the new field and my field name changes. Sighs of relief were heard in the mancave office…

I made the rest of the name changes, tossed another test field in there, got the form updated, and then deleted (and refreshed again) the test fields. Everyone was happy, and the “must have by 1 pm” was made with minutes to spare.

I still don’t know why a field name change wouldn’t trigger the form refresh, but I now know I can force it by putting a new field in the list, which WILL trigger the refresh.

In the Notes world, Joe Litton used to call this type of stuff “TJN” (“That’s Just Notes”). In my SharePoint world, I use the “TJS” variation…

So what’s happening when you see an email with “@domain.invalid”?

I had a strange occurrence in one of my SharePoint workflows that took me far longer to resolve than it should have… pesky typos!

I had a SharePoint Designer 2010 workflow that would send out emails based on various settings on a list item. The emails were sent to people in a SharePoint permissions group, so it was easy to add/remove people who needed to get the information. I’ve done that in many workflows, and it works perfectly…

… until it doesn’t.

In this case, I had a series of permission groups that started with NMPT in the name. When the emails went out, the creator of the item would get a copy, but the To address was coming out as “NMTPRestOfGroupName@domain.invalid”. I tried looking up @domain.invalid online, but I could find nothing that came close to my situation.

Maybe your eyes are better than mine or your mind is sharper, but it took me a while to figure out that NMPT is not the same as NMTP. Basically, I had incorrectly typed in all the group names in the workflow, and SharePoint was trying to send to a mailbox with that incorrect name, but it didn’t know what domain to send it to.

Once I fixed the names in the workflow to start with NMTP instead of NMPT, everything worked like a charm. 🙂

I put this out here so that the next time someone searches for @domain.invalid in the context of a SharePoint workflow, they’ll have something that may work to resolve their issue.