Suchergebnisse

Hallo zusammen, Nach dem mich der ErfinderdesRades überzeugt hat das das MVVM Pattern und WPF einfach gut zusammenpassen hab ich mein komplettes Testprogramm neu geschrieben ich habe versucht das MVVM komplett durchzuziehen dazu habe ich ein paar Verständnisfragen und auch ein paar Problemchen ich packe das alles in diesen Thread rein. Problem 1: Einbindung des MainModels in die Applikation Das Mainmodel bzw. die Klasse wird ja in der Application.xaml als Application Resource eingebunden: XML-Qu…

Hallo Ok d.h. Mit der Fehlermeldung leben. Zum anderen Thema der v_helper dazu da um auf das aktuelle der ObservableColl zuzugreifen eine Art Workaround weil eben die Listcollection zickt wie wir schon einmal hatten wird diese nicht aktualisiert wenn in der ObsColl mit .local die Datenbank reingeladen wird d.h. Itemcount der __transstatus ist 3 der der Transstati ist 0 da half mir auch dein Example EF Simple nicht... Vielleicht interpretiere ich auch das Viemodel falsch? (sry schreibe grad vom H…

Nabend, Ich weiß es ist komisch aber so ist es was mir aufgefallen ist ist folgendes: Hier nochmal die Definition: VB.NET-Quellcode (2 Zeilen) Das Load Event: VB.NET-Quellcode (8 Zeilen) Das Load Event funktioniert auch allerdings ist mir aufgefallen das er im Part __transstatus = dbo.trans_status_v01.local danach das CollectionChanged Event nicht feuert. Ich habe probeweise das __transstatus mit einer For Schleife mal von Hand mit .add gefüllt da wird das CollectionChanged Event gefeuert und di…

@Counterbug Jup sollte er zumindest lt. Codedefinition: VB.NET-Quellcode (2 Zeilen) (Auszug aus der DbSet Klasse) @ErfinderDesRades OK das war mir nicht bewusst ich dachte die CollectionChanged wird gefeuert wenn sich an der Collection selbst etwas ändert weil im Code ja das steht: VB.NET-Quellcode (6 Zeilen) Ich interpretierte den letzten Part eben so das die komplette Liste ausgetauscht werden kann und das Event dann feuert... Somit bleiben 2 Fragen über: Kriege ich das zum laufen ohne die Lis…

Jup ist unterschiedlich 3 / 0 wie gesagt das Problem hatten wir beide schon einmal in einem anderen Thread. Ich habe jetzt die Klasse so umgebaut: VB.NET-Quellcode (14 Zeilen) Weise also der Transstati ListCol erst nach dem Laden aus der DB die __transstatus zu das funktioniert der Count wird nun synchron gehalten 3/3 Mein Problem mit der Aktualisierung hat sich damit nicht gelöst ich musste dazu noch den "Pointer" bewegen: VB.NET-Quellcode (9 Zeilen) Die Frage ist ob das wirklich eine schöne Lö…

sry aber ich checks nicht ich habe mich an deinen Code gehalten. Vielleicht ist es ein Struktur Problem das ich aber nicht erkennen kann: Main Mainmodel: VB.NET-Quellcode (68 Zeilen) Meine vom Entity Framework erzeugte Entität trans_status_v01 VB.NET-Quellcode (14 Zeilen) Mehr gibt es da nicht wenn ich in der Routine TransStatusLoad nicht das "gedönse" mit .local und der Zuweisung mache habe ich keine Werte und mein .count bleibt 0 weil ja aus der DB nix geladen wird. Ich habe keine eigene Klass…

Hm mir fällt grad auf das ich mich da in ein "Problem" verlaufen hab Mit den Codeänderungen lässt sich das Observable und die Listcollection synchron halten. Eigentlich ist das Problem jetzt das folgende: Die View lädt in der Listbox die Elemente sauber rein. Bei Klick auf ein Element wird die "Detail-View" korrekt geladen. Ändere ich jetzt die Property "bezeichnung" als Beispiel von Text 1 in Text 2 dann wird diese Änderung nicht sofort in der Listview angezeigt und auch nicht wenn ich speicher…

Ich habe eigentlich die Klasse um das NotifyPropertyChanged erweitert: VB.NET-Quellcode (4 Zeilen) Das hat aber anscheinend nicht gegriffen ich habe jetzt auf Fody und PropertyChanged.Fody zurückgegriffen: VB.NET-Quellcode (8 Zeilen) Jetzt klappt es bleibt mir nur mehr die Frage wie bringe ich es hin das der User auch gefragt wird ob er die Änderung wirklich übernehmen will?

Was jetzt klappt: Ändern des Datensatzes in der Detail-View und automatisches Aktualisieren in der Listview. Wann soll die Frage kommen: Szenario: Benutzer wählt in der Listview Eintrag aus wird im DetailView angezeigt. User ändert eine Property z.b. bezeichnung Wie es derzeit ist: sobald Änderung der Property erfolgt ist wird die ObservableCollection geändert ob der User will oder nicht Wie es sein soll: Änderung wird nicht übernommen erst wenn "Save" Button gewählt wird oder eine Änderung in d…

WYSIWYG ist ja ganz gut aber mal ehrlich wenn ich bei jedem Create oder Edit einen Dialog setze kriegt der User doch die "Dialogeritis" mich persönlich (und das ist jetzt nur meine Meinung) stört es ziemlich wenn ich in Programmen arbeite und ich klicke irgendwo und plop wieder ein Dialog dann vom Dialog nochmal ein Dialog usw. IMHO ziemlich unübersichtlich. Das Problem in diesem Beispiel ist für mich das die trans_status Entität ja nur eine Art Nebenentität für den eigentlichen Programm Zweck i…

Der Vorteil von Fody ist in diesem Fall das ich nicht für jede Property einen eigene PropertyChanged Event bereitstellen muss, sicher verhindert es das gesamtheitliche Verstehenvon INotifyPropertyChanged nur in diesem Fall überwiegen meiner Meinung nach die Vorteile es quasi "quick and dirty zu machen" Auf Fody bin ich im Zuge meiner Recherchen zum Thema gestoßen github.com/Fody/Fody es ist anscheinend recht mächtig und bietet eine große Anzahl an Möglichen "injections" sprich Addings an die man…

Genau das hätte mir auf Basis dieses Vorschlags hier: msdn.microsoft.com/de-at/library/ms743695(v=vs.110).aspx geblüht. Allerdings hab ich mir mit "Fody" jetzt durchaus ein kleines Problem aufgerissen wenn ich den Dialog so betreiben möchte wie du vorschlägst also ohne dediziertes Speichern zu klicken erhalte ich natürlich keine Meldungen das sich in meiner Collection ein Property geändert hat was ich somit nicht in eine "Reaktion" zum Speichern umsetzen kann. Da muss ich mir jetzt überlegen doc…

Doch ich muss reagieren die Änderungen am ListCollection bzw. Observable gegen ohne Update sonst nicht zurück in die DB liegt wahrscheinlich am .local aufruf aber einmal savechanges aufgerufen und gut ist. Für meine Wunschlösung habe ich mittlerweile auf die Commit und Cancel Methoden der Listcollection zurückgegriffen klappt somit auch wunderbar.

Dagegen spricht das sich die Collection innerhalb des Programmes sofort ändert wenn eine Property geändert wird aber das Rückspeichern in die DB sonst nicht angestoßen wird. Das könnte z.b. zum Verhalten führen der User ändert einen Eintrag von "A" nach "B" arbeitet im Programm weiter und kann überall "B" auswählen beim nächsten Programmstart steht aber überall "A" wie gesagt habe abgefangen und somit kann keine Inkonsistenz entstehen.

Hmmmm tja... *facepalm* zuviele Bäume gesehen gg