Introduction Consider the following scenario: There is a large source list with more than 20 entries You have a destination list with a lookup Field (single-lookup) to the source list For the destination list, you created (or have to possibility to create) custom new and edit forms If you look at the new / edit form of the destination list, you will see that the dropdown rendering is no longer a simple <select> HTML element, but a complex dropdown with filtering possibilities. In some cases, this is really great, but sometimes, you just want a simple <select> element also with big lists (especially if you have a ajax updating script for example, which populates this dropdown). Solutions There are several possibilities. One good solution I found was from here: http://sharepointegg.blogspot.com/2010/10/fixing-sharepoint-2010-lookup-drop-down.html This solution uses only client script (jQuery), and does not change the rendering directly on the server. My solution (only possible on customized new / edit forms) Since I allready customized the new and edit form, I had the full control over the form self (which elements should be placed on the form / which parameters do they use). So I had a form build with the following elements for each column: <tr runat="server" id="FormField_FieldName"> <td width="190px" valign="top" class="ms-formlabel"> <h3 class="ms-standardheader"> <nobr> <SharePoint:FieldLabel runat="server" ID="field_FieldName_Label" ControlMode="New" FieldName="FieldName" /> </nobr> </h3> </td> <td width="400px" valign="top" class="ms-formbody"> <SharePoint:FormField runat="server" ID="field_FieldName" ControlMode="New" FieldName="FieldName" /> <SharePoint:FieldDescription runat="server" ID="field_FieldName_Description" FieldName="FieldName" ControlMode="New" /> </td> </tr> With this markup, you get a standard SharePoint 2010 form field rendered. In my form, I rendered all fields of my destination list with the above markup construct (just changed the "FieldName" to the actual field name), including the lookup field. After some testing, I noticed that the lookup dropdown was rendered very weird (the behaviour described in the introduction) and I needed to change that to get a standard <select> tag. After looking at the source for the SP:FormField control using the RedGate Reflector, I saw the following part: if ((((this.DataSource != null) && (this.DataSource.Count > 20)) && (!base.InDesign && SPUtility.IsIE55Up(this.Page.Request))) && !SPUtility.IsAccessibilityMode(this.Page.Request)) { .... } This is where the descision is done, if the dropdown should render a normal <select> element or a complex complex filtering dropdown. What is this code part deciding? ( Check if the DataSource != null AND Check if the DataSource.Count > 20 ) AND ( Check if the bool InDesign is false AND Check if the current request is from a IE5.5 (or more) ) AND Check if the current request is NOT in accessibility mode After looking at the code, I only saw one possibility to "override" this hardcoded >20 limit... I decided to set the property "InDesign" to true on the FormField. I was feeling bad about this change.. I tried to find out what exactly this "InDesign" property does on the FormField, but I did not found any documentation about the property or the use of it... So I only saw this solution. After changing the form HTML markup of the lookup field to this markup: <tr runat="server" id="FormField_FieldName"> <td width="190px" valign="top" class="ms-formlabel"> <h3 class="ms-standardheader"> <nobr> <SharePoint:FieldLabel runat="server" ID="field_FieldName_Label" ControlMode="New" FieldName="FieldName" /> </nobr> </h3> </td> <td width="400px" valign="top" class="ms-formbody"> <SharePoint:FormField runat="server" InDesign="true" ID="field_FieldName" ControlMode="New" FieldName="FieldName" /> <SharePoint:FieldDescription runat="server" ID="field_FieldName_Description" FieldName="FieldName" ControlMode="New" /> </td> </tr> *tadaaa*, the dropdown was working excelent and it rendered the <select> markup as expected! :) Conclusion I found a solution for this problem, but anyway, I'm still feeling bad about this change... is anyone out there who can explain the use of this "InDesign" property on the FormField Control? Or is it just inherited and unused? If there are any comments or informations available for this, please leave a comment! Also leave a comment if it was working on your site! :) So, this is it for today! Happy coding and may the source be with you! :)

On one of our SharePoint Servers, we got a problem on activating a Sandboxed solution in a SiteCollection.The following error occurs: The sandboxed code execution request was refused because the Sandboxed Code Host Service was too busy to handle the request. After some googling around, I found the following page, which gives a overview about what a sandbox does exactly:http://www.bluedoglimited.com/SharePointThoughts/ViewPost.aspx?ID=318 Now, I used the following PowerShell script on the server, to update the property MaximumWorkerProcesses: $sandbox = [microsoft.sharepoint.administration.spusercodeservice]::local $sandbox.Tiers[""].MaximumWorkerProcesses = 5 $sandbox.Tiers[""].Update() After this change, I restarted the "Microsoft SharePoint Foundation Sandboxed Code Service" and tried to activate the solution again, and voila, the solution was runing. So be aware of the fact, that the Sandboxed Code Service is by default configured to use one Tier with one WorkerProcess which accepts one connection (what is really too less if you only have one Sandbox-Server, to run any solution on it!).

Here is a small snippet to get a TermSet out of the Managed Metadata Service from SharePoint 2010: string siteUrl = "http://SITEURL"; using (SPSite localSite = new SPSite(siteUrl)) { // Create Taxonomy Session TaxonomySession taxSession = new TaxonomySession(localSite); // Get the 'Managed Metadata Service' TermStore TermStore taxStore = taxSession.TermStores["Managed Metadata Service"]; // Get the 'UserProperties' Taxonomy Group Group taxGroup = taxStore.Groups["UserProperties"]; // Get the 'TermSetName' Termset TermSet taxSet = taxGroup.TermSets["TermSetName"]; foreach (Term term in taxSet.GetAllTerms()) { string termDescription = term.GetDescription(); if (String.IsNullOrEmpty(termDescription)) { termDescription = "No description available"; } Console.WriteLine("Term {0}: {1}", term.Name, termDescription); } }

Here is a super article, describing the Dialog Framework in SharePoint 2010. It also gives a perfect how-to for a sample dialog. http://www.chaholl.com/archive/2010/11/17/using-the-dialog-framework-in-sharepoint-2010.aspx

Because of the fact that the SharePoint way of changing the userprofile propery order is a pain, here is the coding-way doing this task: string siteUrl = "http://SITEURL"; using (SPSite localSite = new SPSite(siteUrl)) { SPServiceContext serviceContext = SPServiceContext.GetContext(localSite); int displayOrder = 10; ProfileSubtypeManager psm = ProfileSubtypeManager.Get(serviceContext); ProfileSubtype ps = psm.GetProfileSubtype(ProfileSubtypeManager.GetDefaultProfileName(ProfileType.User)); ProfileSubtypePropertyManager pspm = ps.Properties; // update display order of the property pspm.SetDisplayOrderByPropertyName("PROPERTYNAME", displayOrder); // important: commit the display order! pspm.CommitDisplayOrder(); } You need a instance of the local SPSite. With this, get a SPServiceContext instance.Then you need a ProfileSubtypeManager instance (the ordering is managed by the ProfileSubtypeProperty out of the ProfileSubtype). and finally a ProfileSubtypePropertyManager. To Update the displayorder finally, don't forget to call the "CommitDisplayOrder()" function.

To get the configured Display Value of a Field in a SPListItem, use the following Code: new SPFieldLookupValue(SelectedListItem["FIELDNAME"] as String).LookupValue Another way would be: SelectedListItem.GetFormattedValue("FIELDNAME") The second snipped displays also a hyperlink to item in the lookup table (surely it must be a lookup field, otherwise just the value will be displayed).