Posts Tagged ‘Javascript’

Monday, June 29th, 2009

SharePoint Tricks: Allow Duplicate Column Names

One of the restrictions of SharePoint I always stumbled upon when clicking a SharePoint site together was the one of duplicate column names. I bet you’ve all seen it. You’re creating some columns (list or site ones) and suddenly SharePoint gives you this error:

SharePoint Tricks: jfjfjf

SharePoint Tricks: Duplicate column name error

I finally got pissed at this problem, so I decided to investigate. Now, as I developed some columns through the feature framework, I knew it was possible to create columns with the same name, Display Name that is. Just look at Title. How many different “Title” columns can you see in the edit view screen? So I decided to take a look in the fldnew.aspx page, and what did I discover? A nice javascript array with all “forbidden” column names. I tried to make that array empty and tried again. Magic! The column name was approved. For some reason the team decided to block duplicate names off. But I feel this can be handy some times, especially when creating site columns. You are bound to hit this limitation some time.

But what does SharePoint do¬†internally? It will always make a unique internal name (eg. if you enter Title, it will create a field with Title0 as internal name and Title as display name) A good practice however is to first create a field with a “good” internal name. Good meaning, no spaces, no weird characters, clear. And afterwards renaming it using this trick. Now, what is the trick you will ask? Well, quite simply: once the fldnew.aspx or fldedit.aspx page is loaded. Head toward the address bar of your browser and enter following javascript.

javascript:g_FieldName={};alert('ok');

This code will clear the “forbidden” column names array and give you a visual confirmation when you can go on.

I hope this little trick will help some of you guys. Use it with wisedom however. :-) ’till next time!

Wednesday, July 23rd, 2008

SharePoint Branding Issues: Edit In Datasheet View

For a couple of weeks now, I’ve got some reports about crashing datasheet views when using custom master pages. As a reminder, the datasheet view is a view you can select when browsing within a list. It’ll enable you to view and edit the list in an excell-like format. Quite handy for bulk changes.

So, what is happening? I noticed the page was going into an infinite loop. When debugging I stumbled upon the GC-functions. Those functions are located in core.js and control the resizing of the datasheet view control. After carefull reviewing, I noticed the document.documentElement.scrollHeight was growing and growing. It seemed that my custom master page let the scroll height go out of it bounds.

To fix this, I simply bound the scroll height to the client height. To accomplish this, you look for

var lGCWindowHeight=document.documentElement.scrollHeight;

in core.js and replace it with

var lGCWindowHeight=(document.documentElement.scrollHeight>document.documentElement.clientHeight) ? document.documentElement.clientHeight : document.documentElement.scrollHeight;

This seemed to solve the problem and stopped the browser from crashing.

But why was this happenning? My best bet is the use of a specific doctype in my masterpage. In quirks mode, IE includes top and bottom borders and padding widths when calculating the offsetheight. Standard mode only defines the content height as offsetheight. I’m guessing core.js relies on the extra margins. Now, the strange thing is, the custom master pages of MOSS (BlueBand, OrangeSingleLevel, …) do not experience this bug, altough they also use a specific doctype. I didn’t really investigate into it too much, but I suspect they restrict the height of some container surrounding the main content. This could stop the growth of offsetheight. If anyone of you, readers, can confirm this behaviour, feel free to respond in the comments.

In the meantime.. have fun branding!

Update: according to reader Rufino, you can also revert this behaviour by specifying a height. Didn’t test it yet, but I’m pretty sure this ‘ll do the trick too. Thanks Rufino!