Personalizzazione dell'albero di ereditarietà DependencyObject

Question

Non riesco a trovare informazioni sufficienti sulla proprietà Albero ereditario (o contesto di ereditarietà) utilizzato da DependencyObject e DependencyProperty.

Vorrei utilizzare la capacità valore di ereditarietà di DependencyProperty al di fuori di una tipica pagina di WPF, in modo tale che l'oggetto A è la logica genitore oggetto B, e quindi un valore assegnato a una proprietà su oggetto A verrà automaticamente propagarsi ad oggetto B a meno che non sia stato impostato localmente (un po 'come la proprietà FlowDirection funziona in WPF).

Se Object A e oggetto B sono derieved da DependencyObject, e sono non figli di un UIElement (in altre parole, l'oggetto A è il proprio radice), allora come si fa a stabilire l'albero logico in modo che DependencyProperty capisce che B è figlio di A?

Il e Josh Smith's bag of tricks non sono proprio quello che sto cercando. I non voglio recuperare proprietà da un albero di elementi esistente ... Voglio creare il mio albero di elementi non visivo ... cioè avere il controllo sul contesto di ereditarietà.

Qualcuno sa dove si nasconde questo corpo di conoscenze?

Answer 1

Dopo molte ricerche e cavarsela in qualche modo il codice sorgente per DependencyObject, ecco la risposta breve:

Il InheritenceContext (la proprietà che rivela il padre logico di un esempio) è (come il 90% della realizzazione utile di DependencyObject) contrassegnato come interno e quindi tenuto nascosto da ogni codice esterno WindowsBase.dll

è possibile usare riflessione per impostare il campo _contextParent, nonché chiamare questo metodi nascosti per impostare il InheritenceContext, ma alla fine il giorno non è una soluzione pulita.

Dopo aver setacciato il codice sorgente DependencyObject, devo dire che non sono impressionato. DependencyObject potrebbe e dovrebbe essere una classe molto pulita, onnipresente e riutilizzabile. Invece è strutturalmente e comportamentalmente legato ai suoi ereditari, e contiene anche costanti, campi, metodi e aggettivi specifici per aiutare Freezable a coesistere con il resto delle sottoclassi, che non solo si allontana dal buon design OO, ma rende anche una classe altrimenti superba completamente inutilizzabile al di fuori del framework WPF.

Answer 2

Suppongo che tu stia chiedendo la propagazione dei valori ai bambini che non sovrascrivono i valori stessi.

Il concetto di un elemento WPF con un figlio è introdotto da ContentControl per quanto ne so. Questo entra in gioco molto più in basso nella gerarchia di quanto tu voglia andare. Quindi, suppongo che se dovessi semplicemente derivare da DependencyObject che questo comportamento non si manifesterebbe.

In particolare, un bambino deve sapere di chiedere al genitore se non ha un valore per una determinata proprietà.

Interessante domanda. Mi piacerebbe anche conoscere la risposta completa.