Have you ever worked on a web project that was required to work cross browser and also across several versions of the browser. Chances are you have as most companies require, at a minimum, the site to work in IE6 and FireFox.

A project I  recently worked on required the team to set up Virtual Machine with IE6 installed to test the graphical layout of the web application. The test VM was needed due to the fact that you can't install IE 6 and IE 7 on the same machine and all of our developers were working in IE7. This is a painful process for something as simple as the testing across several browser versions.

I just watched a presentation by Scott Guthrie (http://videos.visitmix.com/MIX09/KEY01) and he outlined a new tool for Expression Blend called SuperPreview. What this does is allow you to check your presentation layers cross browser and in different browser versions. It displays a split screen view that demonstrates the position of an elements such as div tags on your screen via the DOM. The left split shows the element position in a browser of your choice... FireFox for instance, the right split shows the elements position in another browser instance such as IE6 but it also displays the elements position in FireFox so you can get a good comparison on how much the elements may be out of whack. This tool seems essential in my opinion for front end developers. The download is available at http://blogs.msdn.com/xweb/archive/2009/03/18/Microsoft-Expression-Web-SuperPreview-for-Windows-Internet-Explorer.aspx. The trial version is 250MB.

The other day I was modifying a custom site template for SharePoint. I actually had to create some list views for pages that I was provisioning through some modules. Because the template was copied from an out of the box site template, Team Site, it already had some views in it.

One of the views had a property called list which was $Resources:core,lists_Folder;/$Resources:core,announce_Folder. This was obviously targeting a list and you could deduct from the value that it was an announcements list. But what exactly is the value this represents. To find this out you need to first locate the core.resx file. This file is located in the /12/Resources folder.

Once you locate this file, using the string in the list property mentioned above, we can then search for the values. E.g. search for lists_Folder will give you the value of Lists. Searching for announce_Folder will give you the value of Announcements. So here we have Lists/Announcements. Pretty obvious in this example but what about all the other resource strings dotted throughout the SharePoint ether? First of all you need to find the correct resx file to search. The value after $Resources: represents what file to search e.g. $resources:core would mean the file is core.resx. In another example, such as in a page in layouts, you will find a lot of the string $Resources:wss. The file we need to look for in this instance is wss.resx. This is not located in the Resources folder we were previously looking. To find the file the best way is to do a Windows search for *.resx in the 12 hive. This lists out all the resx files used by SharePoint. You will find that wss.resx exists in 12/CONFIG/Resources.

Use this method when you need to determine the what strings mean. Don’t change the resx files however as you will be modifying every site in the farm.

Sometimes a customer may request that various fields should not be displayed in certain list forms. SharePoint lists have a number of forms that are used to view, create and update field data.

These fields are called dispform.aspx, editform.aspx and newform.aspx. There are a few ways you can edit these forms. Some people use SharePoint Designer, I personally never use it. In a nutshell you can insert a custom list form into one of the list forms I mentioned previously and then go to town on it by deleting or inserting fields. Here is a link on how to customize the NewForm.aspx. I'm not to sure about how this approach is long term as I am unsure that when you add new fields to your list for instance that the changes are reflected on your customized form.

Another way to show/hide fields is to modify the list schema.xml file of any custom lists you create. To be honest I tried using this approach on a custom list to hide some fields but did not have much luck. The list was installed by a WSP and activated in the site definition and didn't pick up the fact that I had said to ShowInDisplayForm="false" for a number of fields. Why it didn't I am yet to discover. I had a custom content type declared in the list schema however the content type was not set up as separate feature. Maybe if I set the ShowInDisplayForm="false" in the field declaration feature. e.g. the element manifest file called columns.xml that sets up custom fields and is specified as part of the content type feature. So that approach was a no go for me.

The approach I am going to discuss now was by far the easiest for me. That is to hide fields programmatically from a list from. In my instance it was the display form. To achieve this all I had to do was connect to my SharePoint site. I used a console application to run all my tests before I actually include them into my deployment packages. Here is the code to insert in your Console Application:

                using (SPSite site = new SPSite("http://Your Site"))
                {
                    using (SPWeb web = site.OpenWeb())
                    {
                        Console.WriteLine("Get List Object");
                        SPList list = web.Lists["Powers"];                       
 
                        foreach (SPField fields in list.Fields)
                        {
                            Console.WriteLine("Field: " + fields.Title.ToString());
                        }
                        SPField listField = list.Fields["Your List Field To Hide"];
                        listField.ShowInDisplayForm = false;
                        listField.ShowInEditForm = true;
                        listField.ShowInListSettings = true;
                        listField.ShowInNewForm = true;
                        listField.ShowInViewForms = true;
                        listField.Update();

                        Console.WriteLine("Show field " + "Your List Field To Hide" + " in display form:  " + listField.ShowInDisplayForm);

                    }
                }

It's fairly straight forward and allows you to set the ShowInDisplayForm = false. Upon compiling and running the application you can refresh your list view form in the browser and the field should be hidden. The other list forms are also specified in the code in case you want to hide them from other forms also. You will note the update is done on the listField object not the actual list. I tried for ages trying to get my changes to occur only to realize I was updating the list object. This does nothing to update the fields. I am also listing out the fields of the list using the loop to get the exact display name of the fields. Obviously not required though so you can delete this out if you want.

So far my experience is telling me that not all fields can be switched on or off. All the custom fields in the list can be shown or hidden but  I am having difficulty with one SharePoint field nameley the "Approval Status" field. This states whether an item is approved, pending etc Hopefully I can get to the bottom of this one.

Once you are happy with your code you can easily insert this into a feature activated event as part of a feature receiver to save yourself the hassle of having to manually hide the field using the console application.

If you need to develop the branding of a MOSS site chances are you will use one of the developer toolbars that can be enabled in your browser. IE and Firebox both supply there own versions. Some would argue that the Firefox developer toolbar is better but that is not the point of this post.

You may have difficulty getting the IE toolbar to work after you first download and install the plugin. The symptons I'm referring to are that you can see the toolbar but every option is greyed out. After looking around the internet a bit it seemed that I was not alone. To solve the issue simply select Tools > Options from the IE menu. Select the advanced tab and under the Browsing section make sure that "enable third party browser extensions"* is checked. Close and start up a new window of Internet Explorer and check to see that you can select the items in the developer tool bar.

Have you ever wondered how it would be possible to increase the width of a Form Field such as a multi-select box? To see what I mean create a custom field in a list. This can be a lookup to a list that allows multiple values. When you create and edit an item the width of the select box is governed by a DIV that is hard-coded and wraps the form element (select box). create and edit a new item in teh list. If you do a search on the source code of your editform.aspx for example, you will find a div tag specifying absolute width and height: <div style='width:143px;height:125px;overflow:scroll'>

The div tag restricts how much text is being displayed so if you have some fairly big strings you may only see half of them. I did spend quite a while trying out a few options e.g. embedding classes into the Table Cells that contained the Div and few other bits and pieces but eventually found I could use a JQUERY to modify the DOM at runtime and set new widths for the "problematic" DIV tag.

This technique works really well if you are deploying the list and its fields as features as you can insert this code directly into the any forms such as the editform.aspx and newform.aspx and not have to go into SharePoint Designer to access your form pages.

Firstly download the jQuery core code http://docs.jquery.com/Downloading_jQuery. Place this script file in the 12 hive somewhere. I used a new folder in the layouts folder e.g .../12/templates/layouts/myfolder

Create another js file to contain your code. In this js file insert the following jQuery. Save the js as myjquery.js:

$(document).ready(function() {

$("td.ms-input div").css("width", "300px");
$("td.ms-input div").css("height", "125px");
$("td.ms-input div").css("overflow", "auto");
$("td.ms-input div input").css("width", "300px");
$("td.ms-input div select").css("width", "300px");
});

Using basic inheritance rules the jQuery will find the any input and select boxes contained within the table cell with a class of ms-input. It will then locate the the DIV nested in that table and apply a width of 300px.
If you have access to the editform.aspx located in your feature then insert the reference to the jQuery base code and your jQuery code files as follows.

<script type="text/javascript" src="/_LAYOUTS/myfolder/jquery-1.2.6.min.js"></script>

<script type="text/javascript" src="/_LAYOUTS/myfolder/myjquery.js"></script>

I placed my references into the PlaceHolderMain content placeholder.

if  you dont have access to the form you want to modify via a feature you will need to use SharePoint Designer to open up the form. Save the form and make sure your paths to your JS files are correct and make sure when you browse the form in the browser that your changes are actually being applied. The last thing you want to worry about is caching pages so do an IISRESET to be sure.

I have started building up our Accessible moss portal master page borrowing the same methods applied to the AKS master pages. These include labeling tables as layout tables and using the wss search control. I have added in my own labels for the scopes drop down and search input box as this is required to comply with accessibility standards. Doing this I have managed to narrow the accessibility errors down to 2 for the portal home page which is pretty good. I am using WAVE to test the accessibility. The errors I am getting are for missing "alt" text for some blank.gif images. I tried to find them but they are in SharePoint controls that I can't modify. The 2 errors is 1 lower than the amount for the AKS master pages.

I also converted the DOC TYPE to “loose” instead of running in quirks mode. What happens when you do this to the default master page? Well the height="100%" for tables, cells and rows will no longer work so you are left with a portal that does not extend the full height of your browser. You can work around this however if you set some background images to repeat vertically. This will give the impression that your site fits the height of the browser. It can also be achieved for fixed width or liquid layout sites.

Lately I have been craving some fresh podcasts and videos to load on my ipod touch and listen to/watch whilst I am at work. I have been hunting through google but have been unsuccessful in digging anything up. The best I have found so far are those delivered to my inbox via rss from the http://blogs.msdn.com/sharepoint/. If any of you are not already subscribed to this then I recommend getting onto it. It's SharePointy gold straight from the source.

Training videos are frequently displayed revolving around development tasks in Visual Studio 2008.

If anyone has some other good links please feel free to post them up

I have been working on a SharePoint Case Management Portal Project for some time now and we've just finished iteration 3 now. When the site was first designed and built, the custom SharePoint menu looked cool. Each item had its own icon and each icon meant something as it was not really overwhelming on the eye. We've added in a whole bunch of new icons and now the menu looks terrible.

I've been browsing the web researching GUI design principles when I came across a site called IxDA (Interaction Design Association). It’s not your typical "look at this design" site but a forum for discussion regarding Design Patterns, Tools, Research and Methods regarding Web, Desktop, Mobile and any other type of Interface design. I highly recommend a read if you want to stimulate your brain into gear with some good quality discussion.

So what am I going to do about my menu. Well so far I have built up mental model of all the items that make up the menu. I have given the idea of a tree menu some thought but I find the idea of an expanding/contracting tree menu a bit cumbersome. Whilst this would certainly help with the issue of keeping the menu height small (when tree items are contracted) the thought of having to implement this in SharePoint and the Value it will add really don't seem too attractive to me. 

In terms of what we currently have, the items are grouped into two sections -  All items of type "View" e.g. view details, view notes etc were in one group and all actions items in a separate group. In all the there are 22 items which makes for a lengthy menu. Potentially too long if we want to ensure that majority of items are visible in a 1024 resolution. I like the idea of limiting the amount of clicks the user would have to do to get to a page. This means that splitting the site up into a 2 level hierarchy would not really do the job. By this mean having top level menu items that would link you through to sub-sites for a given action with the rest of the menu options provided on the sub-site. Hmmm decision decisions.

Well I’ll mess around about in Photoshop I think to see how it could look. But in the mean time check out IxDA

Just a had a colleague ask me how to set the Master Page for a WSS site. I had to cast my mind back to a project I worked on a while ago in which two techniques were used to set the Master Page. One way was editing the "Modify All Site Settings" page, accessed through the Site Actions button, which involved a modified user interface to allow an administrator to actually pick a master page from the gallery as you would in a standard Moss publishing site. This technique is actually packaged as a web part at CodePlex.

The other technique involved using features to deploy a master page to the master page gallery and then using another feature to set it as the sites master page by using code within the FeatureActivated SPFeatureReceiverProperties.

The below code from the FeatureActivated method also sets a logo and theme that I had created. This can be ommitted if you don't need to set this. As always I create an additional folder within the Images folder in the 12 hive just incase any service pack updates that are applied to a SharePoint installation overwrites my files.

public override void FeatureActivated(SPFeatureReceiverProperties properties)
        {
            SPWeb newWeb = (SPWeb)properties.Feature.Parent;

            newWeb.AllowUnsafeUpdates = true;

            //Apply web theme
            newWeb.ApplyTheme("none");
            newWeb.ApplyTheme("Your Theme");

            //Apply Logo
            newWeb.SiteLogoUrl = "/_layouts/images/YourFolder/YourLogo.gif";
            newWeb.SiteLogoDescription = "Logo Description";

            //Check if MasterPage exists in Master Page Gallery   
            foreach (SPListItem listItem in newWeb.Site.RootWeb.Lists["Master Page Gallery"].Items)
            {
                if (listItem["Name"].ToString().Equals("YourMasterPage.Master", StringComparison.OrdinalIgnoreCase))
                {
                    //Found Master Page So apply it to the current web
                    string masterUrl = new Uri(newWeb.Site.Url).GetComponents(UriComponents.Path, UriFormat.Unescaped);
                    if (!masterUrl.StartsWith("/")) masterUrl = "/" + masterUrl;
                    if (!masterUrl.EndsWith("/")) masterUrl += "/";
                    masterUrl += "_catalogs/masterpage/YourMasterPage.master";
                    newWeb.MasterUrl = masterUrl;
                    newWeb.CustomMasterUrl = masterUrl;
                }
            }

Today I had a bit of spare time to attempt an installation of the Accessibility Kit for SharePoint. The kit can be download from Codeplex or the AKS site itself. The file size is around 17MB

One of the things I discovered after installing AKS file is that it really is only built for public facing MOSS sites at the moment. What you get when you install the kit is basically a feature that sits within your Features folder on the file system. It’s the one called AKS. Using the STSADM tool you can install and activate the feature for a given site collection. This will deploy a bunch of AKS master pages and CSS file onto you site. Navigate to the site collection where you activated the feature and browse to site settings and the master page and page layouts gallery. You will find the new master pages titled AKS_BlueBand.master and several others. The CSS is deployed to the style library. A good source of information for exactly what happens can be found at CMS Wire.

I hope to crack open the master pages for a good look and run the pages through an online checker such as ATRC. We are currently building some Accessible SharePoint sites for some Government agencies however we built it using our own master pages so it will be interesting to see how this one stacks up. So far the AKS master pages I have applied look pretty good. There is an issue with the site actions menu playing up a bit in terms of styling widths on mouse hover.

Hopefully have some more on this fairly soon. So far so good with the AKS install

At the moment I'm just looking into an extremely interesting bug within the sharepoint spell checker. One of my colleagues, Fred  Schwass, informed me that when you type in certain words the default language drop down appears asking you to select a language (Australian in our case) even though  we have explicitly set to default to Australian anyway.

Normal functionality performs as follows. Enter your text, submit your form or check your text, spell checker highlights suggested words

Buggy functionality perfroms as follows: Enter your text, submit your form or check your text, spell checker requires you to select default language, spell checker highlights suggest words

It's funny because you type in "Innacurate" or "Orange tree" and it produces the bug however typing in "orange" or "tree" will not produce the bug. There are also certain words that trigger the spellchecker to check the words in spanish.

Recently I was doing some work for a client around setting up an advanced search page and some scopes. The client has several web applications set up and the Shared Service Provider (SSP) is indexing all the web applications. There are several scopes we set up specificly grabbing content from one of the web applications on the SSP. These scopes are set up to grab data that have specific content types.

The problem arose when we tried to set the default scope on the advanced search page. By default the scope for advanced search is All Sites. However when you set the scope to be a custom scope and ensure that no other scopes are active when you return to the advanced search page and search for an item it will return results from every single web application. This is very strange behavior and one which I am curious to hear if anyone has experienced anything like this.

The only way to return items from the custom scope is to modify the advanced search web part and specifically enable scopes on the web part. You then have to select the scope by ticking the check box and click search. I would have thought that by setting a default scope through Site Actions > Site Settings > Modify All Site Settings > Search Scopes on the advanced search section that this would cover it. Maybe there is something I have overlooked. Of course one solution would be to set up seperate SSP's for the web applications but geez I would like to know why it won't work.

The monthly Perth SharePoint User Group meeting is on next tuesday at 12:30 pm. This provides sharepoint developers and prospective sharepoint customers with a great opportunity to link up with some of the great resources we have around Perth plus you get free Pizza. How cool is that? For all the details see the information provided kindly by Rick Rosato below.

http://www.connectedsystems.com/news/Event%20Library/Perth_SharePoint_User_Group_Meeting_April_2008.aspx  

I've been playing with the advanced search for a client and wanted to do something fairly straight forward. All I wanted to do is disable the language picker and result type picker. The language picker is the one allows you to search only the language(s) such as French, German etc. Both these features were not required by the client but they did need the custom scopes I had set up to be visible to allow further filtering. So what's the problem I hear you ask? Well after modifying the Advanced Search Web Part to disable the features and enable the scopes it kept on throwing the error "Object reference not set to an instance of an object."

Initially I though this could be caused by not specifying a label for the scopes but it was still throwing the error even after supplying labels. After much enabling and disabling of scopes, languages and results it did eventually display the way I wanted but it was sporadic at best. My solution of trying combinations until worked is not really a solution and how do you document this for a client?

"Um Just fiddle with with a bit until it works and then don't ever touch it".

After searching around for a resolution I hit the wall. A few posts suggest that Service Pack 1 for SharePoint is the cause of the problem. If anyone knows anything about this please let me know.