Net 'n vinnige waarneming dat daar 'n baie belangrike verskil tussen hierdie twee definisies:

<FieldBind Veld = "InParam1" Designer Tipe = "String Builder" ID = "2" Text = "invoer parameter # 1" />

teenoor:

<FieldBind Veld = "InParam1" ID = "2" Text = "invoer parameter # 1" />

Die eerste programme soos dit in SPD:

terwyl die laasgenoemde soos hierdie toon:

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 🙂

Die waarneming is dit: StringBuilder kan jy 'n tou te bou (natuurlik) deur die meng die string vasgekodeerde en workflow data (via the "Add Lookup" knoppie in die linkerkantse hoek). When you use the Add Lookup button, it inserts a token in the form "[%teken%]". When SharePoint invokes your custom action, (C # kode in my geval), SharePoint gaan die teken self, not the value of the token. If you use the default designer type (Die tweede soort), SharePoint brei uit die teken en die werklike waarde van die teken te bowe gaan aan jou optrede.

StringBuilder = BAD, standaard ontwerper tipe = GOEIE.

Natuurlik, 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 (wat toevallig presies wat 'n mens 'n dinamiese onderwerp te skep vir die e-pos aksie, maar dit is 'n onderwerp vir 'n ander blog inskrywing, is).

<einde />