When using SPUtility.SendEmail() to send an e-mail message from within a site on which anonymous access is enabled, you have to specify the from address.

The code in the fragment below is executed in the SendEmail method and explains why:

email = messageHeaders["from"];

if (email == null){  email = web.CurrentUser.Email;}else{  email = FoldEmailHeader(email, "from", true);  count--;}

The code listed above is being executed in the SendEmail method (obtained by using Reflector). As you can see, if the “from” address is not in the StringDictionary “messageHeaders”, the from address is being retrieved from web.CurrentUser. Since anonymous access is being used, this will obviously fail.

In the project we’re currently working on, we have a masterpage with a JavaScript powered menu. In this masterpage, a JavaScript function with the name HideUnhide was defined to toggle the visibility of parts of the menu. 

While testing one of our webparts, I came across a weird problem in which the page containing the WebPart was not rendering if a QueryString parameter with the name “ID” was specified. Fortunately, Google helped me out listing this blog post in the search results.

For the project I’m currently working on, I needed to develop a WebPart which provides (among other functionality) a download link to a file stored in the database. I’ve used a LinkButton to render the download link and in it’s Click event I’m retrieving the file from the database and output it to the Response stream like this:

Page.Response.ClearContent();Page.Response.Cache.SetCacheability(System.Web.HttpCacheability.NoCache);Page.Response.ContentType = "application/pdf";Page.Response.AddHeader("Content-Disposition", "attachment; filename=document.pdf");Page.Response.Buffer = true;Page.Response.BinaryWrite(file);Page.Response.End();

Now, when a user clicks the download button, a File Dowload Dialog is displayed in the browser. When this dialog is closed the page is not responding to any click within the webpart’s content that normally would cause a postback to occur. With a little Googling, I found this thread which fully describes the cause of the problem and provides a neat solution.

I was experiencing problems openening the “Datasheet View” of a SharePoint list. In my case, the issue was that ActiveX components where not allowed to run in the browser due to some security settings. While googling to find this solution I found some other things that might have caused the problem. Here they are:

• The browser is too old: IE 5.01 with SP2 is required
• The “Microsoft Office Access Web Datasheet Component” is not installed. This is included in Office 2007 and also available on the Office 2003 installation disc