Solo un'osservazione rapida che c'è una differenza molto importante tra queste due definizioni:

<Campo FieldBind = "InParam1" DesignerType = "StringBuilder" ID = "2" Testo = "Parametri di Input # 1" />

contro:

<Campo FieldBind = "InParam1" ID = "2" Testo = "Parametri di Input # 1" />

La prima mostra come questo in SPD:

mentre la mostra di quest'ultima come questo:

Non sono sicuro di quanto siano utili queste schermate, ma mi impegno a farle in modo che tu debba vederle 🙂

L'osservazione è questo: StringBuilder consente di generare una stringa (ovviamente) mescolando insieme le stringhe letterali e dati di flusso di lavoro (tramite il "Add Lookup" pulsante in basso a sinistra). Quando si utilizza il pulsante Aggiungi ricerca, inserisce un token in forma"[%token %]". Quando SharePoint richiama l'azione personalizzata, (Codice c# nel mio caso), SharePoint passa il token stesso, non il valore del token. Se si utilizza il tipo predefinito di progettazione (il secondo tipo), SharePoint si espande il token e passa il valore effettivo del token a vostra azione.

StringBuilder = cattivo, tipo di finestra di progettazione di default = buono.

Naturalmente, che è non quello che voglio dire davvero. Basta non cercare di passare un parametro per l'azione personalizzata quando la finestra di progettazione digitare = StringBuilder. Utilizzare il tipo di progettazione predefinita e catena un StringBuilder ad esso davanti se è necessario costruire stringhe complesse nel vostro flusso di lavoro (che per inciso è esattamente ciò che si fa per creare un oggetto dinamico per l'azione di e-mail, ma questo è un argomento per un altro blog, har har).

<fine />