Microsoft has just announced that they received certification from the U.S. Department of Defense for records management. 

Specifically it's 5015.2 certification.

Design Criteria Standard for Electronic Records Management Software Applications

Which is essentially the industry standard for government records management.

For us developers, this means we no longer have to pair MOSS up with OpenText to have a certified solution.

The TreeView control included in ASP.Net 2.0 is lacking an option to cause a postback due to a user checking/unchecking a checkbox on a tree node.

I hacked together a little derived class to use in place of the treeview that postsback when the user clicks the checkbox, and also fires an event.

It would of course be useful to add a bit more code so that the resulting event could specify which node was changed, etc.  But as of now you can just look at the "checkednodes" property of the tree. 

using System;
using System.Text;
using System.Data;
using ASP = System.Web.UI.WebControls;
using System.Web.UI;
using System.IO;

namespace myNameSpace
{
    class VerboseTreeView : ASP.TreeView, IPostBackEventHandler 
    {
        public event EventHandler CheckClick;

         protected override void Render(HtmlTextWriter writer)
        {
            StringBuilder builder = new StringBuilder();

            using(StringWriter stringWriter = new StringWriter(builder))
            {
                HtmlTextWriter tempWriter = new HtmlTextWriter(stringWriter);
                base.Render(tempWriter);
            }

            string find = "<input type=\"checkbox\" ";
            string replace = "<input type=\"checkbox\" onClick=\"" + getPostBack() + "\" ";

            writer.Write(builder.ToString().Replace(find, replace));
        }

        protected string getPostBack()
        {
            return this.Page.GetPostBackEventReference(this, "@CheckPostBack");
        }

        protected virtual void OnCheckClick(EventArgs e)
        {
            if (CheckClick != null) CheckClick(this, e);
        }

        void IPostBackEventHandler.RaisePostBackEvent(string eventArgument)
        {
            OnCheckClick(new EventArgs());
        }

    }
}

It seems one of the more complicated aspects of ASP.Net for many developers is understanding ViewState.  There are many misconceptions about what it does for you, and what it does not do. 

What ViewState is Not

ViewState does not restore user posted values to form controls.  ASP.Net does this for us, but it has nothing to do with ViewState. 

For example:

If the user posts a value to a control, checking a checkbox for instance, and a postback occurs, ASP.Net will restore this value for you in the 'ProcessPostData' method, which occurs before AND after the OnLoad event.  It happens twice, so that if you were to dynamically create your control in the OnLoad event, it's value would still be restored, although that value would NOT be available until AFTER the onload event was complete.

While this is very helpful to the developer, it has nothing to do with ViewState.

ViewState also will not restore any controls that you generated dynamically.  So if you put a !IsPostBack around your dynamically generated controls, they won't be there when the page posts back.

What ViewState IS

ViewState records the properties that are dynamically changed in your code, whether explicitly, or via data-binding, such that they can be restored on each request.

Example:

If you create a textbox in your pages OnInit method, and in OnLoad set the value of the textbox while !PostBack, the value will still be persisted on postback.

After the OnInit method completes, and all controls that may need their ViewState restored already exist, the "LoadPageStateFromPersistanceMedium" method executes and repopulates the value of your textbox.

Keep in mind that if a user had added text to the textbox before posting back, that this too would be available OnLoad, but not due to ViewState, instead due to the 'ProcessPostData' event.

I worked with Microsoft's Eric Charran on a previous engagement, and was pleasantly surprised to see a very helpful article he put together recently.

http://msdn2.microsoft.com/en-us/library/bb428899.aspx

Summary:

Learn to properly conduct team-environment development of Microsoft Office SharePoint Server 2007 sites and assemblies (Web Parts, site templates, custom list templates), as well as develop Microsoft Office SharePoint Designer artifacts (master pages, workflows, CSS sheets). (13 printed pages)

Also, some updates on virtualization releases from Microsoft might be of interest to anyone making use of Eric's team-development strategies.

The SPFileCollection has no 'Exists' or 'Contains' method you can use to verify the existence of a file.  It seems the appropriate method is to first Get the file, which will not fail if the file does not exist.  Once you have the file, you can check an 'Exists' property.

  In my case I needed to overwrite the existing file, which meant first deciding if it exists, then deleting it.

(Where web is an SPWeb object)

                if (web.GetFile(FilePath).Exists)
                    web.GetFile(FilePath).Delete();
                web.Folders["FolderName"].Files.Add(Filename, data);