Hallo zusammen,
wie kann man denn ein default Binding fuer ein ICommand in einer DependencyProperty festlegen?
Mein Ziel ist ein default Binding zu dem "EditCommand" herzustellen, das EditCommand befindet sich auf dem ViewModel, meine base class kennt das ViewModel jedoch nicht.
new Binding("EditCommand"), steht als Platzhalter.
public ICommand DoubleClickCommand
{
get { return (ICommand)GetValue(DoubleClickCommandProperty); }
set { SetValue(DoubleClickCommandProperty, value); }
}
// Using a DependencyProperty as the backing store for DoubleClickCommand. This enables animation, styling, binding, etc...
public static readonly DependencyProperty DoubleClickCommandProperty =
DependencyProperty.Register("DoubleClickCommand", typeof(ICommand), typeof(DataGrid), new PropertyMetadata(new Binding("EditCommand")));
Vielen Dank,
Manullino
Was genau hast du vor?
Dein ViewModel erbt von deiner BaseClass, in dem sich die DependencyProperty befindet, sehe ich das richtig?
Du kannst ein abstraktes EditCommand in der ViewModelBase einführen was die spezifischen ViewModels implementieren müssen.
Sorry, hätte vielleicht erwähnen sollen, dass die DependencyProperty von einem Control ist, was auf der View ist.
Bisher hatte ich das einfach uber eine direktes Binding in XAML gloest. Nun habe ich aber eine baseclass des Controls und diese soll als default an den EditCommand des ViewModels gebunden werden.
Vielen Dank,
Manullino
Ich glaube das ist so nicht möglich, da dir beim Binding-Objekt der Wert für die Source-Eigenschaft fehlt und nur der Wert der Path-Eigenschaft bekannt gemacht wird.
Das geht nicht, du weißt doch gar nicht auf welcher View das Control liegt und ob es in dem ViewModel dann so ein Command gibt. 😉
Hatte die Hoffnung, dass man das im Code tricksen kann, oder ein fallback gibt, wie in XAML.
Du könntest im Loaded-Event vom Control das Binding im Code setzen.
Wirklich gut finde ich das aus den genannten Gründen aber nicht.
NuGet Packages im Code auslesen
lock Alternative für async/await
Beim CleanCode zählen nicht die Regeln, sondern dass wir uns mit diesen Regeln befassen, selbst wenn wir sie nicht befolgen - hoffentlich nach reiflichen Überlegungen.
Hi Palladin007,
Wie wuerdest du das genau machen, weil das Control die View nicht kennt?!
Vielen Dank,
Manullino
Wozu muss das Control die View kennen, es ist die View 😉
Es kennt das ViewModel nicht, aber das muss es auch nicht kennen, da die Bindings zur Laufzeit ausgewertet werden.
this.SetBinding(DoubleClickCommand, new Binding("DefaultDoubleClickCommand");
Das sollte so funktionieren.
Aber wie gesagt: Gut geht anders 😉
Du kannst auch Mal probieren, ob das im Loaded-Event sein muss, oder ob es auch im Konstruktor reicht.
Als Default-Wert direkt in der DependencyProperty-Definition geht nicht, da die BindingExpression instanzbezogen arbeitet. Sie braucht also das DependencyObject und das gibt es zu diesem Zeitpunkt noch nicht.
NuGet Packages im Code auslesen
lock Alternative für async/await
Beim CleanCode zählen nicht die Regeln, sondern dass wir uns mit diesen Regeln befassen, selbst wenn wir sie nicht befolgen - hoffentlich nach reiflichen Überlegungen.
Wozu muss das Control die View kennen, es ist die View 😉
Dessen wäre ich mir nicht so sicher, zumindest hört es sich für mich nicht so an. 🤔
Für mich klingt es so, als wenn er ein Custom Control (mit DependencyProperty) hat, was er auf irgendeine View legt.
Und das Custom Control wiederum hat jetzt eine Basisklasse.
Die Zusammensetzung ist doch egal, Bindings gehen immer gegen ein DependencyObjekt, egal ob's nun ein CustomControl, UserControl oder Window ist.
Aber ja, man kann über meine Aussage, ob das die View ist, streiten. Ein CustomControl ist es vielleicht nicht, weil es da streng genommen noch keine View (in Form vom Content oder Template) gibt. Für die Fragestellung ist das aber nicht relevant.
NuGet Packages im Code auslesen
lock Alternative für async/await
Beim CleanCode zählen nicht die Regeln, sondern dass wir uns mit diesen Regeln befassen, selbst wenn wir sie nicht befolgen - hoffentlich nach reiflichen Überlegungen.
Ich glaube wir reden aneinander vorbei bzw. es kann auch sein, dass ich seinen Aufbau falsch verstehe. 😁
Er hat
a) eine View
b) ein ViewModel mit EditCommand
c) ein CustomControl
d) eine Basisklasse für das CustomControl mit DependencyProperty
Und die DP der Basisklasse soll standardmäßig an das EditCommand des ViewModel binden. Habe ich das soweit richtig verstanden?^^ 🤔
Das SetBinding
würdest du im CustomControl bzw. in der Basisklasse machen?
Das knallt ja spätestens dann, wenn das CustomControl auf eine View gepackt wird, die kein "EditCommand" hat.
Klärt mich mal auf. 👅
So hab ich's auch verstanden.
Ich würde nur "technisch" nicht zwischen View und CustomControl unterscheiden, beides ist ein DependencyObject und verhält sich im Bezug auf die Bindings gleich.
Das SetBinding würdest du im CustomControl bzw. in der Basisklasse machen?
Anders geht es nicht bzw. ein anderer Weg kenne ich nicht.
Das knallt ja spätestens dann, wenn das CustomControl auf eine View gepackt wird, die kein "EditCommand" hat.
Genau das ist das Problem, deshalb finde ich das Vorhaben auch nicht gut. Es bleibt aber ohne Exceptions, da WPF für Bindings keine Exceptions wirft.
Das Problem hast Du aber immer, egal wie Du das Binding setzt.
NuGet Packages im Code auslesen
lock Alternative für async/await
Beim CleanCode zählen nicht die Regeln, sondern dass wir uns mit diesen Regeln befassen, selbst wenn wir sie nicht befolgen - hoffentlich nach reiflichen Überlegungen.
Viel interessanter als die Frage, warum es so technisch nicht umsetzbar ist, fände ich ja die Frage, was damit überhaupt erreicht werden soll. Also welche Anforderungen damit implementiert werden sollen. Ich vermute ja, daß sich das Problem schon durch die Verwendung von InputBindings lösen könnte.
Weeks of programming can save you hours of planning
Ich tippe auf Faulheit.
Einen Zusammenhang, den man mit InputBindings lösen könnte, sehe ich da nicht, denn da müsste man ja auch ein Command setzen.
Aber da fällt mir noch etwas ein:
Muss der Default-Command ein Binding sein?
Wenn es eine Command-Klasse ist, kann man die sehr einfach als Default setzen und hat keine Nachteile, wenn es das ViewModel nicht gibt.
NuGet Packages im Code auslesen
lock Alternative für async/await
Beim CleanCode zählen nicht die Regeln, sondern dass wir uns mit diesen Regeln befassen, selbst wenn wir sie nicht befolgen - hoffentlich nach reiflichen Überlegungen.