blog.richardramdat.com

We had several  users reporting an error when deleting a SharePoint team site. The error appears as a “File Not Found.” on the WebDeleted.aspx layout page along with a stack trace. It appears that the problem stems from our custom master page. For our implementation we use a custom HttpModule that redirects incoming requests for a master page to virtualized custom master pages that we maintain.

The WebDeleted.aspx page references the simple.master page which we redirect to our customized application master page. Apparently this results in the page trying to load in elements that are out of context for it. The solution was to stop redirecting simple.master and instead route it back to the SharePoint out of the box simple.master.

For the past two SharePoint implementations that I’ve worked with, it was a common business requirement to query from a list to retrieve items that should be displayed on a “scheduled” basis. Think along the lines of an alert or announcement. Typically what I end doing is create a custom list and add the following three fields, “StartTime”, “EndTime” and “Active”. Start and End Time are the fields for scheduling the list item. I make them a Date+Time field and also allow them to be optionally be null, this way someone can create an open ended item that starts at a specific time but has no specified End Time. The Active field is a simple yes/no that is a convenient kill-switch or safety check.

So with the three columns, the following CAML query can be used to query items that should be currently displayed:

So you have an instance of a SPListItem and want to know whether this item belongs to a Document Library or if it came from a list (such as an Event Calender, Survey, or Custom List). A quick way to distinguish a document library item is to access the ParentList property of the SPListItem class and examine the BaseType. In code,

SPListItem item = GetItemFromSomeWhere();

if (item.ParentList.BaseType == SPBaseType.DocumentLibrary)

{

// This item is from a document library – it probably contains a file.

}

So my previous Microsoft Fail post would make you think that I exclusively hate Microsoft. Surprisingly I think those guys in Redmond do come out with some genius ideas every once in a while (emphasis on the ‘once in a while’ :-) So in all fairness, here starts the Microsoft Win list:

1. Xbox 360 – countless hours of happiness!
2. C# – one of the most beautiful languages ever written for a computer.
3. ASP.NET – started out as a web framework with so much potential and it has never failed to deliver.
4. .NET Framework – an endless repository of win!
5. Windows 2000 – the perfection of an operating system – for its time.
6. Microsoft Excel – spreadsheets rock!
7. Active Directory – unlike any network directory service you’ll ever encounter.
8. LINQ – because I’ll never use a foreach loop to search through an object collection ever again.
9. Surface Computing - the single most *real* advancement for true ubiqtious computing beyond personal devices.
10. Zune HD – despite lacking phone capabilities – a marevelous piece of hardware with equally amazing software integration.

There is a known SharePoint customization bug that under certain circumstances, modifications to a master page (ie, use of a doctype or margin/padding) will cause the “Edit in Datasheet” mode to crash Internet Explorer.

The underlying problem is caused by a poorly written function called GCComputeSizing within Core.js The common fix is to override this function by defining your own function called GCComputeSizing in a script reference that is loaded in after the reference to Core.js is called in your master page.

However, what most of the other blogs and resources fail to mention is that Core,js can sometimes be loaded in using the “defer” attribute of the script tag. When this happens, core.js will now be loaded in after the page is loaded. Unless you also defer your override script, you will invoke the built-in GCComputeSizing function and the bug will persist.

This problem was specifically noticed when using user-defined or custom datasheet views. Comparing the source html for standard and custom datasheet view yieled the following:

Standard Datasheet View:
<script type=”text/javascript” language=”javascript” src=”/_layouts/1033/core.js”></script>

Custom Datasheet View:
<script type=”text/javascript” language=”javascript” src=”/_layouts/1033/core.js” defer></script>

As you can see, only custom datasheet views were loading in core.js  as a deferred script. Adding the defer attribute to our custom override script fixed this problem by deferring the override after the deferred core.js was loaded.

In terms of overriding GCComputeSizing  there are many examples easily searchable through the interwebs. One word of caution though, as a person who has quite a bit of experience with Javascript, GCComputeSizing not a function suitable for production. Even some of the *corrected* versions that others have posted still make me uneasy. Anything that has the potential of throwing a client’s browser into an infinite loop and locking up their cpu is a serious  cause for concern. Fortunately, our customized design uses a fixed layout so I was able to simplify GCComputeSizing to the following:

function GCComputeSizing(GCObject)
{
    if (TestGCObject(GCObject))
    {
      var lGCWindowWidth=663;
      var lGCWindowHeight=550;

      glGCObjectWidth = lGCWindowWidth;
      glGCObjectHeight = lGCWindowHeight
    }
}

We’ve been interviewing candidates for a director position at work this week and during the interviews I’ve had a chance to notice a couple of things that I thought would be great to blog about.  I’ve conducted numerous interviews in the past, and have myself been a candidate multiple times. Here are some things that I’ve found over the years.

1) In-person interviews tend to be very useless. Meaning that you can perform flawlessly on a job interview and still not be hired. Likewise, you can perform less than stellar and still be selected. What’s going on here? Call it the pre-interview bias. Those hiring know for the most part who they want to bring on. Interviews are used only to confirm their initial feeling. What’s more, an interviewer will probably look past weak points of a favored candidate, but highlight them in the least favored ones. Studies have confirmed multiple times that a decision to hire is usually accurately made within the first couple of seconds of meeting the candidate.

2) Use that pre-interview bias to your favor. Use cover letters, resumes and charasmatic recuriters to sell youself as a star. Your goal is to come across as celebrity. Amongst a stack of candidates and resumes, you should be the favored one.

3) Don’t waste time on companies that are only somewhat interested in you. If it doesn’t feel like a company is overly enthusiastic about the interview or meeting you, then your chances of being hired are usually next to none. Hiring the right person is a painful ordeal for many companies – if they think you’re the perfect fit – you’ll definitely know.

4) Once you’ve been invited out to an interview – just relax. These people already know whether they want to hire you or not, so just go in and be yourself. Smile, agree to what most people are saying, don’t say too much and don’t ever say something negative – like, “I’ve never heard of that product”. Instead, use an agreeable positive attitude all the time - like, “Oh yea, that does sound familiar”.

5) I know I’ve mentioned this above, but it’s worth its own line. Don’t speak too much! Every word exposes you, gives them something to judge you on. If you allow your interviewer to do most of the talking, then you minimize the focus and judgement on yourself. You allow more of their pre-interview bias to be a deciding factor. Always reinforce their pre-interview bias – look impeccable, stand tall, smile, have open agreeable body language, appear confident. This alone is worth so much more than what you can ever hope to convey through words.

6) Don’t miss out on that opportunity to ask questions! They may seem to contradict the above, but when it comes time for you to ask questions make sure you do! Rarely will asking a question hurt you, but quite the opposite. If you have been quiet and reserved for most the interview and now you start asking intelligent and thought provoking question, then not only do you confirm the pre-interview bias – you also end the interview on a very positive note. Asking the right questions can excite and make your interviewer smile and be very happy. This should be your goal.

So you need to get a url reference to a SharePoint list item? Fantastic, just use SPListItem.Url right?

I think by now you can guess that would be too easy. So instead of divulging into my usual SharePoint scarasm, I’ve found a friend who has done a much better job than I could ever pull off.

http://www.sharepointsecurity.com/sharepoint/sharepoint-development/splistitemurl-funky-return-fiesta/

Came across this error while trying to execute a Caml query through the SPQuery object:

One or more field types are not installed properly. Go to the list settings page to delete these fields.

Wonderful, eh? Don’t believe it, you don’t need to delete any fields. You more than likely have a misspelled column or a column name that has a different internal name than what is publicly visible. For example, a default SharePoint calendar has a column field called “End Time”; however if you include the space within your query, you’ll get the error above. In this case, the internal name is really “EndDate”. Also look for column fields that have been renamed. Sometimes if you define a column, then later change its name – the internal name will still remain the same.

So this begs another question – How are you supposed to *magically* know what the internal field name is? Well, here’s a tried and true method. Go to the list you are trying to query from, then click Settings -> List Settings. Scroll down to where all the Columns are defined. Click on the one in question, which will take you to the FldEdit.aspx page. Within your address bar, notice the querystring param Field. This references the internal field name for the column which you should also use in your queries.

See Microsoft,  wasn’t that a lot more helpful then trying to tell the user to delete some random field from their list? Geesh.

Living life without cable tv and a dvr for the past couple of months has been relatively painless. Mostly due to summer tv reruns. Now that fall is approaching with a slew of new shows (quality television!) I’m beginining to get a bit nervousous about missing out on shows that don’t fit my schedule.

Of course I can resort to Hulu or downloading tv shows… or I can get this marvelous little device:

It’s the world’s smallest USB tv tuner which allows you to view and record over the air broadcast television on your computer. It costs about $80 (which could easily be one month’s cable bill). Combined with the features of my new Windows 7 computer (post upcoming!) - I think this could definitely work!

One of the nice features of SharePoint 2007 development is the ability to use the latest release of the .NET framework and  its concomitant language features – including Linq. This in and of itself it a huge benefit as the inherit query mechanism within SharePoint – CAML is woefully terrible.

What is CAML? A pain in the arse. Officially, it stands for Collaborative Application Markup Language – which amounts to more bollox than telling you anything you need to know. Essentially, CAML is an xml structured intermediate query syntax for SharePoint to query against data structures (that can also be defined using CAML). Sounds a bit like SQL no? Well guess what CAML gets translated to in the back-end? Yep – SQL. SharePoint takes your CAML and queries against its sql backend. So in short, with CAML you have this massively verbose query syntax that requires nested xml tags, multi-line statements, and quoted attributes – yuck!

Enter Linq, with its terse sql-esque statements and amazing chainability. Yay! No more CAML!!

Not quite.

Linq can only be used against a SPListItemCollection object which must be filled before use. The two most common ways to populate a SPListItemCollection is to either Get all items, or use a SPQuery object and CAML syntax to get a subset of items. As you can see, the dilemia presents itself that if you try to avoid CAML altogether, you will sacrifice performance when querying a list with potentially a large set of items.

So the best solution? Use both. Before using Linq directly to query items, first populate your SPListItemCollection with a CAML query that will do an adequate job of ensuring a manageable subset returned from the database. Then with Linq, fine-tune your SPListItemCollection to further sort and filter your result set. So Caml – Chainsaw, Linq – Carving Knife.

For more information, check out the excellent resource below: 

LINQ and SharePoint Development: The benefits and the pitfalls