Basta unha observación rápida, que hai unha diferenza moi importante entre estas dúas definicións:

<FieldBind Field="InParam1" DesignerType="StringBuilder" Id="2" Text="Input parameter #1"/>

contra:

<FieldBind Field="InParam1" Id="2" Text="Input parameter #1"/>

O primeiro mostra como este en SPD:

mentres que o último amosa 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 observación é este: StringBuilder permite que constrúe unha secuencia de (obviamente) pola mestura de cadeas e datos de fluxo de traballo (via the "Add Lookup" botón na parte inferior esquerda). When you use the Add Lookup button, it inserts a token in the form "[%% Símbolo]". When SharePoint invokes your custom action, (Código C # no meu caso), SharePoint pasa o token-se, not the value of the token. If you use the default designer type (O segundo tipo), SharePoint amplía o sinal e pasa o valor real do token para a súa acción.

StringBuilder = BAD, tipo de deseño default = BO.

Por suposto, that’s not what I really mean. Just don’t try and pass a parameter to your custom action when the designer type = StringBuilder. Use the default designer type and chain a StringBuilder to it up front if you need to build complex strings in your workflow (que, de feito, é o que se fai para crear un tema dinámico para a acción de correo-e, pero iso é asunto para outro blog, foi).

</ Comezo>