Nur rapida rimarko ke tie estas tre grava diferenco inter ĉi tiuj du difinoj:

<FieldBind Kampo="InParam1" DesignerType="StringBuilder" Identigaĵo="2" Teksta="Enigo parametro #1"/>

Kontraŭ:

<FieldBind Kampo="InParam1" Identigaĵo="2" Teksta="Enigo parametro #1"/>

La unuaj rezultoj tiel en SPD:

Dum la lastaj rezultoj tiel:

Mi ne certas, kiom helpas ĉi tiuj ekranpafoj, sed mi penas fari ilin, do vi devas vidi ilin 🙂

La rimarko estas tio ĉi: StringBuilder permesas vin konstrui ŝnuron (Evidente) De miksanta kune laĉi literals kaj workflow datumo (Tra la "Aldoni Lookup" Butono en la pli malalta maldekstra angulo). Kiam vi uzas la Aldoni Lookup butono, Ĝi insertas token en la formo "[%Token%]". Kiam SharePoint alvokas vian laŭmendan agon, (C# kodo en mia kazo), SharePoint pasas la token ĝi mem, Ne la valoro de la token. Se vi uzas la defaŭltan designer tipo (La dua tipo), SharePoint vastigas la token kaj pasas realan valoron de la token al via ago.

StringBuilder = BAD, Defaŭlta designer tipa = BONO.

Nature, Tio ne estas kio mi vere malbona. Nur ne provas kaj pasi parametron al via laŭmenda ago kiam la designer tipo = StringBuilder. Uzi la defaŭltan designer tipo kaj ĉeni StringBuilder al ĝi supre fronta se vi devas konstrui kompleksajn ŝnurojn en via workflow (Kiu parenteze estas ĝuste kio unu faras krei dinamikan temon por la retpoŝta ago, Sed tio estas temo por alia bloga eniro, Har har).

<Fino/>