BinaryJam

I have been doing some messing about with jQuery in SharePoint and I want to understand what is going on when there are multiple declarations of different versions on a page.

The way it seems to work is last one referenced wins.  This is because the execution of the jQuery code sets window.jQuery = the current jQuery object.

I was wondering well what happens to the docReady function pointer stack, as that is surely contained within the version of jQuery that was executed.

Well truth is it’s complicated.  The code you see below will execute 161 and 144 code and the events will occur in each ones own code block (closures), but then the values you get out of jQuery are that of the last one executed despite it being a closure, because the clousre version of $ you call in your first doc ready returns the window.jQuery object,

not your closure so this code will always spit out 1.4.41.4.4 despite executing code

from both code blocks.

What does this mean, I haven’t got a clue, but I encourage you to debug this in firebug and see what code executes where, and if someone can explain to me why I see two function pointers in my 1.4.4 readyList code, that would be nice.

UPDATE:I’ve tried this recently and I dont know what crack I was smokin when I tried this, Im convinced I remember stepping thru two sets of jquery code, but then once inside the prior closure gets the new reference once inside, this is not the case when I just did it in VS2010.   What is still interesting is that any plugins loaded after the first jquery reference are nuked on load of the second jQuery ref.  HOWEVER the doc ready function pointer list is retained and both execute.   I still stand by the next statement.

In conclusion I suppose I would say one version of jQuery would be nice on a page, if MS could kindly put something into sharepoint to manage it so we are all doing the same thing I’d appreciate that, and if the jQuery team could “just finish already”

Now one for the SharePoint people.  You have ran SPDisposeCheck on the dire piece of code your lackey wrote (or youself for that matter) and forgot to run the SPDisposeCheck.  Whoosh loads of entries to validate and change the code for. 

Being good people using TFS for source code and task management you want an entry for each item to check.

Using the built in XML handling facilities from PowerShell this is an easy task.

First run SPDisposeCheck with the output set to XML You will get something like this

You can Easily read XML files in PowerShell with a simple statement

$xmldata = 1(Get-Content c:\test\out.xml)

Accessing the Elements is then just object notation

$xmldata.ArrayOfProblem.Problem

Will return an array of problem items that can be accessed in a foreach $problem and with $problem.ID

So the full code to do this is

Read more…

So you’ve been given a project to work on.  Namely convert this project from this technology to that technology and your in luck because you have TFS.

The pain in the backside bit is now I’ve you have got to enter all the tasks into TFS which in itself is going to take ages.

Enter the wonderful world of Powershell !  This is the kind of repetitive task that PowerShell is good at it can loop thru things and use the .NET object model, Easy!

So here is a code snippet that rips thru aspx pages and creates the TFS entries.

Read more…

Marc Anderson was good enough to comment on my last post, a demo of creating a jQuery extension to the SharePoint search box to suggest Common Terms.

Marc’s comment was related to a compatability problem with safari and chrome when using the “z\\:row” syntax as a selector, also to remind me of the SPServices library which makes calling sharepoints web services a little easier.

So just for him (well everyone really) here is the same example re-worked to use the SPServices library (stored locally in a Doc Library for this code).

Read more…

Whether or not SharePoint actually needs an autocomplete for it’s search box could be debated, and the manner in which I’m about to implement it, well that could be debated also. 

The point of this post was to use jQuery techniques to query a list via its web services and do something flash.  I’m doing it SharePoint 2007 as that is what I have handy and working. 

I will be upfront and honest right now, the code for this is a Mashup from two sources, Jan Tielens and the jQueryUI demo itself, both needed tweaking to come up with something new, but just so you know it’s not been rocket science, hard work was done for me, cheers Jan. 

Read more…

I’ve been having a problem with an app I wrote.  It works great, 99% of the time, but sometimes the ItemAdded event appears not to fire.

Now this is using a list with over 20,000 entries in it and its growing all the time.  An associated list that references this list as a lookup has over 144,000 entries in it.

The event firing problem is becoming more frequent now as more users start using the system, there are at least 20 occurances in that 20,000 items, so it has to be fixed.

Managed to track down an error in the log

System.Data.SqlClient.SqlException: Transaction (Process ID 61) was deadlocked on lock | communication buffer resources with another process and has been chosen as the deadlock victim. Rerun the transaction.

It’s stack trace was similar too this (I cut it down a bit and changed some names, my naming is not this bad)

at Microsoft.SharePoint.SPListItemCollection.EnsureListItemsData()
   at Microsoft.SharePoint.SPListItemCollection.get_Item(Guid uniqueId)
   at BinaryJam.Core.Code.TicketListReceiver.ItemReceiver.ItemAddedActual(Guid SiteId, Guid ListItemId, String UserDisplayName)
   at BinaryJam.Core.Code.TicketListReceiver.ItemReceiver.<>c__DisplayClass11.<ItemAdded>b__e()
   at Microsoft.SharePoint.SPSecurity.CodeToRunElevatedWrapper(Object state)
   at Microsoft.SharePoint.SPSecurity.<>c__DisplayClass4.<RunWithElevatedPrivileges>b__2()
   at Microsoft.SharePoint.Utilities.SecurityContext.RunAsProcess(CodeToRunElevated secureCode)
   at Microsoft.SharePoint.SPSecurity.RunWithElevatedPrivileges(WaitCallback secureCode, Object param)
   at Microsoft.SharePoint.SPSecurity.RunWithElevatedPrivileges(CodeToRunElevated secureCode)
   at BinaryJam.Core.Code.ItemListReceiver.ItemReceiver.ItemAdded(SPItemEventProperties properties)

So as you can see, it explodes on the GetItem.

This was my stupid mistake, a mistake I bet many of you are making every day.

SPListItem item = List.Items[listItemId];

This I believe is the primary cause of the problem as this statement loads the complete List before returning the specific item I needed and as this list grows, remember 20,000 items already, its going to get worse.  Now for most of you this won’t be a problem as you will be just getting the ListItem from the parameters, in my case I have to run as elevated as Im doing lots of stuff with Security Groups, that the entering user may not be in, hence my needing to re-get the List Item in the right security context.

So if your having a problem like this remember, Always use the

List.GetItemByID(id); //Or
List.GetItemByUniqueId(guid);

This may or may not solve my problem I believe it will, if it doesn’t it’s still going to improve the performance of my application.  If your wondering, this is the only time I use this and don’t know why I did, the rest of the App uses getby id or SPQueries.

A Good Article on Performance I did actually read, hence the app performs pretty well, except for this one bug, which is now hopefully fixed.

Been having a problem with SiteProvisioningProvider. Well I haven’t but apparently it causes problems down the line if things are not done in a specific order.

A nice man at microsoft diagnosed the problem and came up with the code you should run to ensure your not messing up the Web.

Here is a posting of the proposed solution to the bug we found (I don’t care if they don’t think its a bug, not sure if they do or don’t but I do!)

http://blogs.msdn.com/joerg_sinemus/archive/2009/11/24/overwriting-spwebprovisioningprovider-provision.aspx

So I like many have a workflow that takes requests for Sites with a bunch of details for costing etc.  Then when approved those Sites are created and permissions allocated.

What we did not have was a record of who actually approved the sites.  Whilst this info is in the workflow history after a while that information gets purged, leaving us with Sites that were approved but by whom we know not.

So this is a simple case of changing the workflow and recording all of the approvers in the SPWeb properties, except that the approvers as we can tell happen to be Sharepoint Groups or AD groups, neither of which contain a history of membership, if AD does none I know how to access and certainly not easy for the customer and in a large membership we still would not know who actually did the deed.

I dug and dug for this and eventually found the User Login that actually did the change and here is how.

In your workflow you need a “Workflow Action” of EventName “OnTaskChanged”, this object in the code behind, when Invoked contains AfterProperties,

string user = OnApprovalTaskChanged.AfterProperties.ExtendedProperties[new Guid("d31655d1-1d5b-4511-95a1-7a09e9b75bf2")].ToString();

The above statement gets the User Login frmo the ExtendedProperties Collection.  It Stores the User under the key of that Guid in a User type field that refers to the Editor.

A list of fields can be found here .

So that’s it, took a lot of debugging and poking about but next time your looking for the actual approving user, take a look here.

I am doing lots of work in Sharepoint that requires resource files in english and german.

With a variety of developers before me different styles of editing the foreign language files emerged.

I think that much better tool support for managing resx’s is required,  and I recently found one that is a great help to us with a vareity of resx’s in various states of translation and existence.

http://resxtranslator.codeplex.com/

This resx tool allows you to pick a file and it displays the nuetral and foreign side by side along with comments and allows you to edit them all at once.  Corking piece of work, some polish would go amiss but Im hard pushed to say where as it does exactly what I need it to do and I can pass it to a non-techie developer.  It still down to me to edit the comments first to identify what needs translating and what definately needs leaving alone.

If you doing multi-language work go and check this tool out it might just help.

If you were one of the two people who read my last post on WSS and PowerShell I updated it a bit and it’s worth checking out the changes.

I thought this time I would just point out some of the very simple statements in PowerShell that differ from your usual C# so that you can quickly make a transition from one to another.

One of the first things any programmer might need to do in a script is conditions so here is a PowerShell condition and how it differs to c#

if ($i -eq 10)
{
    write "It's ten you know"
}

The comparison operator for equals is not "=" or "==" but a scripting style operator of -eq. So this is the first thing you’re going to have to remember.  Other operators are

-gt greater than,  -lt less than,  -ge greater than or equal to,  -ne not equal

There are more I found a simple table of them here.

When dealing with boolean responses its important to know that they are represented by $true and $false so a condition to test this would look like

if ($kidding -eq $false)

{

    write "How strange"

}

Now being good little programmers you’re bound to want to structure your scripts, so functions!  PowerShell has functions, but remember this is not a compiled language but a scripting language, this means you have to declare your functions before you can call them, this is not VBScript where you could have your main at the top and functions below, your execution code starts at the bottom after you declared your functions. 

So declaring a function can be as simple as (there are other ways but I’m sticking with this one for now)

function GoGetMyList($name)
{
    $list=$lists["MyList"]
    return $list
}

The function has a parameter of $name and returns $list.  Now the observant of you will have noticed that I created my $list on the fly giving it a scope of function level, but I access $lists whose scope is outside of the function, ok bad coding perhaps, but it’s to prove a point.

Variable scopes.  There are I believe three scopes  Global, Script, Stack (function) level.

Global scope is used in the PowerShell environment mostly you can set something of Global level in a script and it will be available on completion of the script in the scripting "Shell/Command Prompt" environment, if you are chaining scripts together this could be useful.

Script scope.  This is like a global or module level variable to your script code, once declared it’s accessible inside and outside all your functions

Stack/Function scope.   Declare a variable inside a function it’s scope and life-span are inside that function.

The weird thing is how you declare and reference these variables.  So here is how to define 3 scopes within a function

function GetBaseObjects($SiteUrl)
{

    $script:site = New-Object Microsoft.SharePoint.SPSite $SiteUrl
    $script:web = $site.RootWeb
    $script:lists=$web.Lists
    $script:list=$lists["MyList"]
    $item=$list.GetItemById(1)
    $Global:DispName=$item.DisplayName
    return $item
}

Now this is a thoroughly useless function but it demonstrates the differing levels.

$script:site = New-Object Microsoft.SharePoint.SPSite $SiteUrl

The $scipt:site  declares the variable at a script level accessible from another function or the script "main body", there is no need to pre-declare these variables because at EVERY assignment you make it sets the scope, this is a valid set of statements

function dave()
{
    $script:tellme="Script"
    write $tellme
    $tellme="function"
    write $tellme
}
dave
write $tellme

This will display "Script", "function" and "Script".  This is because PowerShell with search each scope for a variable and if not there it looks up the inherited variable scope tree, for want of better words.  The first time referenced we have a script level but the second time we have a function level and the third time the function itself is out of scope along with its variables so we access the script level one again.

So remember the order of your functions when setting scope level variables and ALWAYS when setting a variable to define the scope.

That’s all for this post, I’ll try and do another one encompassing error handling and arguments in a complete script that changes SharePoint settings.