Apenas uma rápida observação que há uma diferença muito importante entre estas duas definições:

<Campo FieldBind = "InParam1" DesignerType = "StringBuilder" ID = "2" Texto = "Parâmetro de entrada # 1" />

comparação:

<Campo FieldBind = "InParam1" ID = "2" Texto = "Parâmetro de entrada # 1" />

O primeiro mostra como este em SPD:

enquanto a segunda mostra como este:

I’m not sure how helpful these screen shots are but I put in the effort to make them so you have to view them 🙂

A observação é isso: StringBuilder permite que você construa uma seqüência de caracteres (Obviamente) pela mistura de literais de cadeia de caracteres e dados de fluxo de trabalho (através do "Adicionar pesquisa" botão no canto inferior esquerdo). Quando você usar o botão Adicionar pesquisa, ele insere um símbolo no formulário"[%sinal %]". Quando o SharePoint invoca sua ação personalizada, (No meu caso o código c#), SharePoint passa o token em si, Não o valor do token. Se você usar o tipo de designer padrão (o segundo tipo), SharePoint expande o token e passa o real valor do token para sua ação.

StringBuilder = ruim, padrão tipo designer = bom.

É claro, Isso é não o que realmente quero dizer. Só não tentem passar um parâmetro para sua ação personalizada quando o designer digite = StringBuilder. Usar o tipo de designer padrão e cadeia um StringBuilder para ele na frente, se você precisar criar seqüências de caracteres complexas em seu fluxo de trabalho (que aliás é exatamente o que se faz para criar um tema dinâmico para a ação de e-mail, mas isso é um assunto para outro blog, har har).

<final />