Sólo una observación rápida que hay una diferencia muy importante entre estas dos definiciones:

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

frente:

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

El primero muestra como este en el SPD:

mientras que el último muestra como este:

No estoy seguro de lo útil que estas capturas de pantalla son más que pongo en el esfuerzo por hacer que lo que hay que verlas 🙂

La observación es esto: StringBuilder permite crear una cadena (Obviamente) mezclando los literales de cadena y datos de flujo de trabajo (a través de la "Añadir búsqueda" botón en la esquina inferior izquierda). Cuando se utiliza el botón de agregar consulta, inserta un token en forma"[%token %]". Cuando SharePoint invoca la acción personalizada, (Código de C# en mi caso), SharePoint pasa el testigo de sí mismo, no el valor de la ficha. Si utiliza el tipo de diseño por defecto (el segundo tipo), SharePoint amplía el token y pasa el valor real del token a su acción.

StringBuilder = mal, por defecto el tipo de diseñador = buena.

Claro, eso es no lo que quiero realmente decir. Simplemente no probar y pasar un parámetro a la acción personalizada cuando el diseñador = StringBuilder. Utilice el tipo diseñador predeterminado y la cadena StringBuilder que delante si necesita construir cadenas complejas en su flujo de trabajo (que por cierto es exactamente lo que uno hace para crear a un tema dinámico para la acción de correo electrónico, pero eso es un tema para otra entrada de blog, Har har).

<final />