Personalizzazione dell'albero di ereditarietà DependencyObject

Question

Faccio fatica a trovare informazioni sufficienti sulla proprietà Inheritance Tree (o Inheritence Context) utilizzata da DependencyObject e DependencyProperty .

Vorrei utilizzare la funzionalità di ereditarietà dei valori di DependencyProperty al di fuori di una tipica pagina WPF, in modo che l'oggetto A sia l'oggetto principale logico B, e quindi un valore assegnato a una proprietà sull'oggetto A proporrà automaticamente all'oggetto B a meno che non sia stato impostato localmente (un po 'come la proprietà FlowDirection funziona in WPF).

Se l'oggetto A e l'oggetto B sono derivati ??da DependencyObject e non sono figli di un UIElement (in altre parole, l'oggetto A è è il proprio root ), quindi come si stabilisce l'albero logico in modo che DependencyProperty capisca che B è figlio di A?

Il Hillberg Freezable Trick as così come La borsa dei trucchi di Josh Smith non è proprio quello che sto cercando per. Non non voglio recuperare le proprietà da un albero di elementi esistente ... Voglio creare il mio albero di elementi non visivo ... cioè avere il controllo sul contesto di eredità.

Qualcuno sa dove si nasconde questo corpus di conoscenze?

Answer 1

Dopo molte ricerche e confusione nel codice sorgente per DependencyObject , ecco la risposta breve:

Il InheritenceContext (la proprietà che rivela il genitore logico di un'istanza) è (come il 90% dell'implementazione utile di DependencyObject ) contrassegnato come interno e quindi nascosto da tutto il codice al di fuori di WindowsBase.dll

È possibile utilizzare reflection per impostare il campo _contextParent , nonché chiamare questi metodi nascosti per impostare il InheritenceContext , ma alla fine non è una soluzione pulita.

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

Answer 2

Presumo che tu stia chiedendo della propagazione dei valori ai bambini che non sovrascrivono i valori stessi.

Il concetto di un elemento WPF che ha un figlio è stato 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 tu derivassi semplicemente da DependencyObject che questo comportamento non si manifesterebbe.

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

Domanda interessante. Vorrei sapere anche la risposta completa.