Slechts een korte opmerking dat er een heel belangrijk verschil tussen deze twee definities is:

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

versus:

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

De eerste shows zoals dit in het EPD:

terwijl de laatste shows zoals dit:

Ik ben niet zeker hoe nuttig deze screen shots zijn maar ik zet in de inspanning om ze te maken, dus je moet om ze te bekijken 🙂

De observatie is dit: StringBuilder kunt u een tekenreeks bouwen (Uiteraard) door het mengen samen letterlijke tekenreeksen en workflowgegevens (via de "Add Lookup" knop in de linkerbenedenhoek). Wanneer u de knop Opzoeken toevoegen gebruiken, het voegt een token in de vorm"[%token %]". Wanneer SharePoint roept uw aangepaste actie, (C#-code in mijn geval), SharePoint passeert het token zelf, niet de waarde van het token. Als u het standaardtype ontwerper (het tweede type), SharePoint breidt het token en werkelijke waarde van het token worden doorgegeven aan uw actie.

StringBuilder = slecht, standaard ontwerper type = goed.

Natuurlijk, dat is niet wat ik werkelijk bedoel. Gewoon niet proberen en een parameter doorgeven aan uw aangepaste actie wanneer de ontwerper typt = StringBuilder. De ontwerper standaardtype en de keten een StringBuilder ernaar vooraan gebruiken als u nodig hebt om te bouwen van complexe tekenreeksen in uw workflow (dat is overigens precies wat men doet voor het maken van een dynamische onderwerp voor de actie e-mail, maar dat is een onderwerp voor een andere blog entry, Har-har).

<einde />