JoelBlogs - Joel Jeffery's Microsoft 365 Blog

Microsoft 365, SharePoint, Teams and Office 365 Architecture, Development, Administration and Training

Removing the Default Editor Parts from SharePoint Web Parts

by

I was recently asked how to remove the Editor Parts (Appearance, Layout, Advanced, etc) from custom Web Parts.

One strategy is to implement your own Editor Part and mark the built-in ones as not Visible.

Firstly, we need to create our Editor Part class:

class MyEditorPart : EditorPart
{
    protected override void CreateChildControls()
    {
        // this line hides the default EditorParts
        Parent.Controls[2].Visible = false; 
        base.CreateChildControls();
    }

    public override bool ApplyChanges()
    {
        // do stuff here
        return true;
    }

    public override void SyncChanges()
    {
        // do stuff here
    }
}

And here’s how we invoke our Editor Part from our Web Part:

public class MyWebPart : WebPart
{
    public override EditorPartCollection CreateEditorParts()
    {
        ArrayList aryParts = new ArrayList();

        MyEditorPart myEditor = new MyEditorPart();
        myEditor.ID = this.ID + "_myEditorPart";
        aryParts.Add(myEditor);

        return new EditorPartCollection(aryParts);
    }
    // do more stuff here...
}

Hopefully, when you edit the Web Part it should look something like this:

The next step would be to extend CreateChildControls(), ApplyChanges() and SyncChanges() to get and set any properties you’d like to allow users to edit.

Workflow Initiation and Association Forms in SharePoint 2010: GetInitiationData, Seralize<T>() and Deserialize<T>()

by

SharePoint 2010 in Visual Studio 2010 has made creating Windows Workflow Foundation (WF) workflows an awful lot easier. There are still one or two areas that can be confusing to new developers

One such region of confusion surrounds the Initiation Form – the form displayed whenever a user launches your workflow, that you can use to prompt for more information required to run your workflow. Similar uncertainty surrounds the Association Form – one that is displayed whenever a list administrator attaches your workflow to their list.

Thanks to the tooling in Visual Studio, it’s now easy to add either of these forms. Right-clicking your Workflow item in Solution Explorer and choosing “Add-> New Item” will give you:

Adding a New SharePoint Item in Visual Studio 2010

Selecting either Initiation Form or Association Form will add the appropriate artefacts to your code and also configures the Element manifest of the Workflow accordingly:

Element Manifest Changes to view Initiation Forms

Let’s say we wanted to ask the user a series of extra questions when they launch our workflow, such as their manager’s First Name, Last Name and Email Address, such that we can have access to that data within our running workflow later on.

We can now edit our new Initiation Form as an aspx page in Visual Studio. Let’s add some text boxes to capture the extra information:

image

The next question is often “how do we get this information to the workflow?” Inside the workflow itself is a SPWorkflowActivationProperties object which exposes two strings: InitiationData and AssociationData, which is respectively the data captured from the user during launch and association phases of the workflow.

The code behind for the Initiation Form has a string method called GetInitiationData(). Whatever string you return here is then available from inside your workflow using workflowProperties.InitiationData. It’s the same principle with Association Forms, GetAssociationData and AssociationData properties.

Clearly, we could go low-rent here and return a semi-colon delimited string or something naff of that ilk.

Alternatively you could store your properties temporarily in a class and then serialise that class to a string and return that. Then later in your workflow you could deserialise that back to an instance of your object.

You could put a lot of effort into this to get it really efficient, but the general principle is why not create a utility class to hold Serialise and Deserialise methods?

I’ve implemented the following candidate code using Generics to show how powerful the technique is:

public static string Serialise<T>(T item)
{
    XmlSerializer ser = new XmlSerializer(item.GetType());
    TextWriter sw = new StringWriter();
    ser.Serialize(sw, item);
    return sw.ToString();
}

public static T Deserialise<T>(string xml) where T : new()
{
    T returnObject = new T();
    XmlSerializer ser = new XmlSerializer(returnObject.GetType());
    XmlTextReader xtr = new XmlTextReader(new StringReader(xml));
    return (T)ser.Deserialize(xtr);
}

So, given a class, for example, to hold contact information: 

public class Contact
{
    public string FirstName;
    public string LastName;
    public string Email;
}

You could put the following in your code behind for the Initiation Form:

// This method is called when the user clicks the button to start the workflow.
private string GetInitiationData()
{
    contact.FirstName = firstName.Text;
    contact.LastName = lastName.Text;
    contact.Email = email.Text;
    return Serialise<Contact>(contact);
}

Then in the code beside for your workflow you can get at the data again like this:

private void codeActivity1_ExecuteCode(object sender, EventArgs e)
{
    Contact contact = Deserialise<Contact>(workflowProperties.InitiationData);
    historyDescription = string.Format("Received Contact information: {0} {1} {2}",
        contact.FirstName, contact.LastName, contact.Email);
}

Hopefully this code will save you some searching and typing.