Bare en rask observasjon at det er en svært viktig forskjell mellom disse to definisjoner:

<FieldBind feltet = "InParam1" DesignerType = "StringBuilder" ID = "2" Tekst = "Input parameter #1" />

versus:

<FieldBind feltet = "InParam1" ID = "2" Tekst = "Input parameter #1" />

Først viser som dette i SPD:

mens de siste show som dette:

Jeg er ikke sikker på hvor nyttige disse skjermbildene er, men jeg anstrenger meg for å lage dem slik at du må se dem 🙂

Observasjon er dette: StringBuilder kan du bygge en streng (åpenbart) ved å blande sammen strenglitteraler og arbeidsflyt data (via "Legg til oppslag" -knappen i nedre venstre hjørne). Når du bruker du legge oppslagsknappen, det setter et token i skjemaet"[%token %]". Når SharePoint påkaller den egendefinerte handlingen, (C#-kode i mitt tilfelle), SharePoint passerer tokenet selv, ikke verdien til tokenet. Hvis du bruker standard designer type (den andre typen), SharePoint utvider token og sender faktiske verdien til tokenet til handlingen.

StringBuilder = dårlig, standard designer = bra.

selvfølgelig, Det er ikke hva jeg virkelig mener. Bare ikke prøv og sende en parameter egendefinerte handlingen når utformingsverktøyet skriver = StringBuilder. Bruk designer standardtypen og kjeden en StringBuilder den foran hvis du trenger å bygge komplekse strenger i arbeidsflyt (som forresten er akkurat hva man gjør opprette et dynamisk tema for e-handlingen, men det er et emne for en annen bloggpost, har har).

<slutten />