WPF Einarbeitung, Anwendung starten, Anwendung vorbereiten (.NET 7)

Amro schrieb:

Bitte verbreite keinen solchen Unsinn. Spätestens wenn du einen DI-Container verwendest und Dependency Injection einsetzt, wirst du es nicht in XAML definieren können, da XAML nur den Basiskonstruktor verwenden kann.

hmm - Unsinn würde ich das deswegen nicht nennen.
Klingt für mich eher nach einem starken Argument gegen Dependency Injection.
Aber ich müsste es mal probieren. Durchaus möglich, dass ich einen Weg finden würde, mir Designtime-Unterstützung trotz DI zu erhalten.
(Sachma frustriert euch das nicht als Entwickler, dass das neueste und dollste eigentlich einen riesigen Rückschritt der Programmiersprache bedeutet? Was war nochmal vor Designtime-Unterstützung - GW-Basic, oder?)

Du bindest an eine statische Ressource. WPF versucht zur Desingzeit diese Ressource zu finden, obwohl sie nicht vorhanden ist. Du musst WPF die Möglichkeit geben, zur Designtime ein Objekt aus dem MainModel zu erstellen, indem es den parameterlosen Konstruktor aufruft.
Zur Laufzeit ist das Objekt irgenwie doch vorhanden und Wpf findet es. Keine Ahnung wie aber es scheint zu funktionieren.

Probier mal das hier:




achte darauf das MainModel im Namespace locla: vorhanden ist.
Das sollte dein Problem beheben.

<local:MainModel /> ist glaub keine gute Idee, weil das instanziert ein Mainmodel .
weil wenn jedes View sich sein eigenes Mainmodel instanziert hat man viele Mainviewmodelse und Chaos.

Haudruferzappeltnoch schrieb:

Wird das Mainmodel mit dieser StaticRessoure Anweisung instanziert?

Ich denke, das MainModel ist in den Resourcen von App.Xaml angelegt.
Dort ist es instanziert, und daran kann alle View binden - ohne dass Dubletten entstehen.

ErfinderDesRades schrieb:

hmm - Unsinn würde ich das deswegen nicht nennen.

Sorry, hast recht Unsinn ist das nicht. Aber es ist kein muss und kein Verstoss gegen MVVM.

Was meinst du mit "warnix". Hast du das selbe Problem?
Mit warnix und geht nicht kann ich nicht viel anfangen. Etwas mehr Infos wären gut.

warnix bedeutet, ich hatte zu schnell losgeblubbert, und nehme meinen post zurück.

Zum Verständnis , MainModel ist das Objekt, das die Daten bereithält,stimmts?
Nennen wir es MainViewModel.
Das Anlegen von Datenobjekten als statische Ressourcen ist für mich neu. Statische oder Dynamische Ressourcen werden normalerweise für Dinge wie Bilder, Schriften und ähnliches verwendet. Deshalb sind das Ressourcen denke ich :).
Klassen mit Eigenschaften und/oder Methoden gehören meiner Meinung nach nicht dazu, da statische Ressourcen anders geladen werden.
Kann mir nicht vorstellen dass es funktioniert, aber anscheinend funktioniert es zur Laufzeit in WPF auf irgendeine Weise.

WPF lädt Daten zur Laufzeit auch anders als zur Designtime, weshalb es gelegentlich Probleme gibt, zum Beispiel bei Bildern, bei denen man d:ImageSource oder so verwendet.
DataContext ist normalerweise das, was für das Binding verwendet wird. Es gibt auch DataTemplates in der App.xaml, wo festgelegt wird, welches ViewModel als DataContext verwendet wird, wenn eine bestimmte Ansicht aufgerufen wird.

ErfinderDesRades schrieb:

Dort ist es instanziert, und daran kann alle View binden - ohne dass Dubletten entstehen.

Das ist schon viel zuweit vorgegriffen , da gibt es Ansetzte wie den Di Container mit Register as Singleton oder Transient.
Du kannst auch beim schliesen der View das Viewmodel Disposen oder das Datacontext lösen oder sonst irgenwie wenn du meinst zu zu viele instanzen entstehen. Wobei ich glaube das WPF sich auch im hintergrund um sowas kümmert. Keine Ahnung bin auch nur Anfänger. Müsste man irgenwie messen.
Am Anfang würde ich mir kein Kopf machen. Das kommt schon früh genug.
Weil es erstmal darum geht zu verstehen wie WPF im allgemeinen funktioniert.
MVVM hat null mit WPF zu tun. Hier geht es nur darum wie du dein Projekt Strukturierts.
Ja basierend auf Model , View und ViewModel aber jedes Projekt kann anders aussehen.
Der Spielraum ist offen und es gibt nicht die eine Lösung. Musste ich auch nach langer Zeit erst lernen.
Wäre ja auch schlimm wenn das so wäre.
WPF lernen ist ein Thema , MVVM ist ein anderes Thema. Du kannst WPF nicht Strukturieren nach MVVM wenn du nicht mal
die Basics der Datenbindung vertstanden hast. Deshalb ist es wichtig WPF zu verstehen , ein Projekt mit Codebehind oder Klassen erstellen das ist egal. Wenn das sitzt , dann erst versuchen nach MVVM zu Strukturieren. Wie gesagt meine Meinung und meine Erfahrung.

Auf jedenfall finde ich das mit der Statischen Resource nicht Richtig.

Ich meinte kein Kopf machen über Sachen die erst verstanden werden können wenn man die Basics versteht.
Sorry wollte dich nicht komplett verwirren. Ich halte mich mal raus.

ErfinderDesRades schrieb:

Dort ist es instanziert, und daran kann alle View binden

Jepp - das ist auf die BeispielSolution von mir gemünzt, die Hdz am Wickel hat.

Wie gesagt: vom Main(View)Model darfs nur eines geben, und eine Lösung ist, es in App.xaml (VB: Appliccation.Xaml) in die Resourcen zu legen.

Ist der Fehler aus post #22 denn nu weg?

So, jetzt habich das Tut selbst nochmal downgeloaded, geöffnet, kompiliert, und dann ins MainView.Xaml geguckt: alles paletti.

Also weiss ich nicht das problem

Und nix wegmachen der / hat eine wichtige Funktion: Dadurch wird an das aktuelle Item einer CollectionView gebunden, und nicht an die ganze Liste.

Haudruferzappeltnoch schrieb:

You only can instantiate MainModel when MainModel.Instance.IsNull or MainModel.Instance.IsProvisional

Dassis doch ein nützlicher Hinweis - den habich programmiert.
Offensichtlich wird dein Mainmodel mehrfach instanziert, for whatever reasons.
Was ja wie gesagt nicht gut ist.

Habe nun einen möglichen Fehler-Grund: Ersetze mal die Public Shared Function IsInDesignMode() As Boolean durch folgende Version: Und dann bereinigen, rekompilieren, VS schliessen und wieder öffnen.

Das dämliche ist, zur Designzeit muss bei diesem Ansatz das Mainmodel mehrfach instanzierbar sein - aber zur Laufzeit nicht.
Also muss man sich eine Public Shared Function IsInDesignMode() As Boolean programmieren.
Die vorherige Variante funzt auch bei WinForms - wo ich das halt auch brauche.
Nur failt das, wenn es MS gefällt den VS-HostProzess mal wieder einen anderen Namen zu geben.
Die neue Variante ist dagegen gefeit, allerdings ist sie auf Wpf beschränkt.

ja genau.
Und mit Process.GetCurrentProcess().ProcessName wird der abgerufen, und ist zur Designzeit ein anderer als zur Laufzeit.

Nachgucken kann man die VS-Prozesse im Taskmanager.

Kannste mir den deinigen mitteilen?
bislang lautet meine Sammlung ja:

ich hab im helpers-projekt den rootnamespace gelöscht.
aber das ist eine heikle sache, heut würdich solch nicht tun.
man kann nämlich den namespace auch so definierenaber sparsam mit umgehen - dass man die MS-Namespaces nicht zu sehr vollmüllt mit eigenem Kram.
Manche Programmierer lehnen das auch insgesamt ab, und sagen: willst du eigene Infrastruktur einbinden, sollste den Import gefälligst auch drüber schreiben.