Pages

October 4, 2018

Fix limited width of lookup fields in SharePoint forms

Ever had pain seeing the full text contents of a lookup field while editing an item in SharePoint? if the answer is yes then you are not alone.
The problem with lookup field controls that allow multiple values is that when items are long, the field box will not adjust itself to show all content as it has a fixed width which hinders the display of a long item.The user has to hover the item to show a tool tip with item title. Imagine doing this for many items!
The thing is the lookup field control is the same old one from SharePoint 2007 era and the UI part of it was not updated in subsequent versions.

Here is what's currently offered by default:
Right before adding any items:
While adding items:
 

From inspecting any SharePoint page that has a lookup field (with 'allow mutliple values'), the control's html should look like this:
<select
name="{wpGuid}SelectCandidate"
title="{Title}"
id="{wpGuid}_SelectCandidate"
style="width: 243px; height: 125px; overflow: auto;"
ondblclick="..."
onchange="..."
multiple="multiple">
<option title="{Option1Title}" value="{Option1Value}">{Option1Title}</option>
<option title="{Option2Title}" value="{Option2Value}">{Option2Title}</option>
<option title="{Option3Title}" value="{Option3Value}">{Option3Title}</option>
...
..
.               
</select>


Solution
The idea is to write a lightweight script to wait for page load, then get all elements where ID contains the phrase "SelectCandidate", and replace the style to remove the 'width' parameter. This will be affect all lookup fields in that page. If no items where selected in that field, it will shrink to minimum width, and when items are added it will expand to the width of the longest item. The result is it will show all contents clearly.


Right before adding any items:
While adding items:


Steps
Do the following for target lists or libraries where you used 1 or more lookup columns with 'allow multiple values' option.

1) Edit NewForm.aspx or EditForm.aspx

2) Add a script editor AFTER the default item view web part

Title:
"Dynamic lookup field width script"

Contents:
<script>
$(document).ready(function () {
$("select[id*=Select]").each(function(){
$(this).attr('style', function(i, style)
{
    return style && style.replace(/width[^;]+;?/g, '');
});
});
});
</script>


 3) Save form!

September 10, 2018

Fixed Issue: JS script unable to edit PDF document in SharePoint

 Setup:

- SharePoint 2013 site: has a library of PDF documents.
- Client machine: Windows 7 with SP1. Adobe Acrobat 2017 installed. Browser is IE 11.
- User calls a SharePoint page with custom JS script to open PDF documents in edit mode using the below js call:
editDocumentWithProgID2( _docRelativeUrl, '', 'AdobeAcrobat.OpenDocuments', '0', _hostUrl, '0');



Issue:

For many users the page script works fine. It instantiates the Adobe Reader ActiveX object to open the document in edit mode. But for some users the script cannot instantiate the Adobe Reader ActiveX object and will throw the following error message:

"The Document could not be opened for editing. A Microsoft SharePoint Foundation compatible application could not be found to edit the document."



 
Digging up:

First. I needed to make sure that Adobe plugin in IE does exist. From IE add-on settings panel, I can see the Adobe PDF Reader plugin (for 32bit and 64bit) with ver.17.8.30051.224877 where file is "AcroPDF64.dll".
What caught my attention is that on another good machine (where the script runs ok) there are 2 plugins: Adobe Acorbat SharePoint OpenDocuments (file is: "AcroPDF.dll") and Adobe PDF Reader plugin (file is "AcroPDF64.dll").

Second, I prepared a test page with script to detect and show the current version of Adobe plugin. That script is using getActiveXObject('AcroPDF.PDF') to instantiate the plugin if available then alert a message to show what version of Adobe plugin if exist.


Test Page Run #1 - on a good machine:

getActiveXObject('AcroPDF.PDF') -> returns [object]{}

Output: "Browser: ie, Adobe plugin installed: true, version: 11"


Test Page Run #2 - on the bad machine:

getActiveXObject('AcroPDF.PDF') -> undefined

Output: "Browser: ie, Adobe plugin installed: false, version: null"


Note: "AcroPDF.PDF" is used for IE 7 and later

So it is clear that JS couldn't find the plugin class, but I saw the plugin in IE add-on panel so what's missing?



Root Cause:

This is an Adobe plugin issue not a js issue. After inspecting the file system, I found that target (bad) machine is missing AcroPDF.dll (and other language-specific dlls too like: AcroPDF.CAT, AcroPDF.DAN, AcroPDF.FRA,..etc) in the following directory:

C:\Program Files (x86)\Common Files\Adobe\Acrobat\ActiveX

This could be because of bad installation for Adobe files, incorrect Group Policy setting or even Anti-Virus/Anti-Malware.



Fix:

Copy the missing AcroPDF.dll and other language-specific dlls to target (bad) machine under directory:
C:\Program Files (x86)\Common Files\Adobe\Acrobat\ActiveX



Final Notes:

Per testing I found that the site has to be added to 'Trusted Sites' zone in IE in order for the Adobe plugin to work correctly and edit required documents. Please check the Group Policy settings if they prevent that.

Recommended setting: To get rid of multiple logon popups after adding url to Trusted Sites, check the ‘Automatic logon with current user name and password’