Sto cercando una soluzione e/o la razionalità dietro al motivo per cui un'istanza di Binding è condivisa in un DataTemplate. Questo alla fine si riduce al fatto che all'interno di un DataTemplate, non c'è apparentemente alcun modo per forzare una nuova istanza di un Binding su una DependencyProperty per ogni controllo generato. Questa è probabilmente una buona e giusta ipotesi in tutti i casi, tranne quando ci sono ValidationRules che rappresentano qualcosa di specifico sull'istanza di quel controllo.Le istanze di binding vengono riutilizzate in DataTemplates quando ValidationRules non può essere condiviso
Per elaborare (posso fornire codice, ma non credo sia necessario), utilizzo DependencyPropertyDescriptor su IsEnabled per aggiornare uno o più ValidationRules che appartengono a un TextBox.Text Binding, DatePicker.Text Binding o un ComboBox.SelectedValue Binding, ecc. L'idea è che la convalida sarà diversa o indesiderata quando un controllo non è abilitato.
Per questo motivo, lo stato di IsEnabled di ValidationRule è specifico per il controllo individuale e poiché la raccolta ValidationRule fa parte del Binding e l'istanza di Binding viene condivisa: ogni controllo che termina la condivisione del binding aggiornerà/sostituirà il valore IsEnabled precedente applicato dal valore IsEnabled del controllo generato in precedenza.
IsEnabled è solo una delle almeno due proprietà in ValidationRule (un'altra proprietà personalizzata IsRequired DependencyProperty) che rappresenta lo stato del controllo a cui è applicato il binding. Quando si lavora all'esterno di DataTemplate (IE: l'istanza di Binding non è condivisa), funziona molto bene e ignora/altera la logica di convalida in base allo stato del controllo. Non sono chiuso alle alternative ma ritengo che questo sia stato (a parte questo problema) un'opzione molto flessibile e dinamica che consente all'istanza Binding ValidationRule e allo stato modificato dal controllo delle Regole di evolvere senza sforzo. Ciò mi ha anche permesso di evitare altre opzioni ovvie ma molto più brutte, come la creazione di più associazioni, ciascuna delle quali rappresenta una delle combinazioni delle proprietà di controllo di ValidationRule e la commutazione dell'intero legame nel momento in cui viene generato DependencyPropertyDescriptor. brividi
Ogni pensiero è MOLTO apprezzato!
Ho avuto esattamente lo stesso problema, e mi ci è voluto un po 'per capire che era il legame che è stato condiviso ... Hai trovato qualche buona soluzione per la tua domanda ancora? Grazie –
L'unico modo che ho trovato intorno a questo è stato quello di creare un binding personalizzato per ogni scenario di validazione/abilitato/richiesto, e scambiare i binding quando lo stato del controllo è cambiato. Questo è stato in realtà meno doloroso di quanto sembri e ho avuto un buon successo con la soluzione. Diventa semplicemente meno ideale all'aumentare della permutazione degli stati. Potete immaginare quanto possa essere disordinato quando avete bisogno di un'istanza personalizzata di un'associazione per ogni combinazione ValidationRule/Enabled/Required. Il mio scenario richiedeva solo circa 12 associazioni personalizzate. Dovresti farmi sapere se trovi qualcosa di meglio. Saluti! – phixed
Sono stato confrontato a questo problema anche in passato. Sono rimasto scioccato anche quando ho scoperto il problema con ValidationRules sull'istanza Binding e l'istanza Binding è stata riutilizzata in uno scenario DataTemplate. Abbiamo un framework che mette un ValidationRule generico su ciascun binding e quindi delega il lavoro di validazione effettivo a librerie di validazione esterne come la convalida di Enterprise Library o qualsiasi altra cosa. – KoenJ