Mehrere Listboxen an gleiche Daten binden.

Hallo

Jeiss schrieb:

Geht das mit einem gewöhnlichen Visual Studio 2015, oder so? Oder brauch man da "Hilfsmittel"? Hab da an Blend gedacht, weil du ja in deiner letzten Antwort "Blend.Interactivity" erwähnst. Kenn das leider noch nicht

Ich habs zwar in VS 2017 erstellt, sollte aber auch in VS 2015 ohne probleme zu öffnen sein. Die dll`s welche ich eingebunden habe wurden von Microsoft für das Blend entwickelt und wenn du in Blend gewisse Trigger einfügst werden diese in das Projekt automatisch eingefügt. Du musst deshalb aber kein Blend installiert haben. Auch auf den Zielsystem muss naturlich nichts installiert werden. Dafür dorgt das NuGet Paket. Dieses zieht die zwei dll`s in dein Projekt und macht sie verfügbar.

Aller läuft wie gewohnt, das Pakte erspart nur einiges an Arbeit.

ErfinderDesRades schrieb:

Thema Mocking

Sorry, aber die benennung ist imho meiner Meinung nach nicht korrekt. Korrekt wäre DesignTimeData oder DesignData oder ähnliches. Mock oder Mocking findet nur bei Unit oder Integrationtests verwendung, Ein Mock ist imho ein Siimulierung, Daten zur Entwicklungszeit sind keine Simulierung.

Sorry, musste sein, aber kann jeder machen wie er will, solange er es dann auch nach längerer Zeit unterscheiden kann.

Grüße LEute
Sascha

Nofear23m schrieb:

Sorry, aber die benennung ist imho meiner Meinung nach nicht korrekt. Korrekt wäre DesignTimeData oder DesignData oder ähnliches. Mock oder Mocking findet nur bei Unit oder Integrationtests verwendung, Ein Mock ist imho ein Siimulierung, Daten zur Entwicklungszeit sind keine Simulierung.

Hmm Gugge Wiki: de.wikipedia.org/wiki/Mock-up , de.wikipedia.org/wiki/Mock-Objekt
Mock heisst "Attrappe", und DesignTime-Daten fasse ich als Attrappe auf - bzw im 2. Wiki-Artikel werden Mock-Objekte als "Platzhalter für Objekte, die für das Testen eines anderen Teils benötigt werden" bezeichnet, und ich find das trifft zu: Ich will sehen, ob die Oberfläche funzt, aber ohne aussm Designer heraus teure Laufzeit-Datenzugriffe auszuführen. Daher brauche ich Daten-Attrappen. (Die lassen sich übrigens bestimmt auch für UnitTests verwenden - evtl. müsste man dafür bisserl das Design zuschneiden - weiss ich nicht - ich bin kein Unit-Tester, aber lass uns das hier nicht diskutieren)
Auf jeden Fall ist ein Mock keine Simulierung, sondern ist eine Komponente (was immer damit gemeint ist), die zur Simulierung dient.

Edit: Aber haste recht - ich hab weiter oben Mocking nur am Beispiel DesignTimeData erklärt, und allein so erklärt muss man den Begriff viel enger auffassen als wie ich ihn eiglich meine (und ich glaube er auch gemeint ist).
Schon

ErfinderDesRades schrieb:

Mocking ist ein Prinzip inne Wpf.

ist ziemlich falsch - es ist ein Prinzip inne Software-Entwicklung, ja sogar auch in anderen Produktions-Zweigen.
Nur während es in anderen Bereichen tw. nur gelegentlich angewendet wird, ists vom Wpf-Designer ja direkt vorgesehen, Mock-Daten anzuzeigen, und gibt ja sogar extra dafür den d:-Namespace (obwohl ich den fast nie brauche).

Hallo

Wollte dich nicht angreifen. KAnn ja jeder bennen wie er will. Nur kurz wegen deinem Link.

Zitat aus deinem Wiki Link gleich in der ersten Zeile:

ist in der Softwareentwicklung ein Programmteil, der zur Durchführung von Modultests als Platzhalter für echte Objekte verwendet wird.

Kann man jetzt sehen wie man will. Wenn man MVVM proggt ist man ja in der Lage UnitTests zu erstellen, und hier muss man gewise Module auch Mocken. Hat aber mit den DesignTimeDaten nicht viel zu tun. Aber wie gesagt, kann jeder handhaben wie er will. Bitte verwende weiterhin Mock. Wollte nur in der Raum werfen das man für UnitTests auch Mocks sagt und hier dann verwirrt sein könnte. Wenn man keine UnitTests macht ist das vermutlich egal.

Fühl dich also bitte nicht angegriffen.

Schöne Grüße
Sascha

ne, fühlich garnet.
einen Moment war ich geneigt, dir recht zu geben, das hätte mich in Bedroullie gebracht, weil dann hätte ich mir ein neues Wort ausdenken müssen für was ich damit meine.
Weisst ja: Ich finde, mit Begriffen muss man korrekt umgehen, sonst weiß man sehr bald selbst nicht mehr, was man redet (s.o.: da stammen dann auf einmal "Daten aus der Listbox" und sowas..).

man kann auch alle im Konstruktor übergeben, aber das kam mir unleserlich vor. With { . ist zwar hässlich länglich, hat aber den Vorteil, dass dann da auch steht, was man zuweist.
Sonst hätteste dem Konstruktor 7 Argumente übergeben, und 3 davon wären Nummern gewesen - recht riskant, da durcheinanderzukommen.
Aber die 5 kann man schon auseinanderhalten, so leidlich.

jo, genau.
Die "inneren" Listen sind übrigens keine reinen Listen, sondern das sind Objekte mit einem WorkCenter-Wert und einer Liste (Zeilen #14, #15).
Und im Xaml werden die eben genau als

Jeiss schrieb:

jeweils eine Textbox und eine Listbox

dargestellt.
(Nein, nicht Textbox, sondern Textblock)

du musst dich jetzt nicht ständig für deine Formulierungen entschuldigen.
Formulierungen sind mir ziemlich egal, auch Grammatik ist mir schnurz.
Nur weil ich einmal hofflich intensiv genug einem (leider extrem gängigen) verheerenden Denkfehler Einhalt zu gebieten versucht hab.

Also solange etwas Sinn ergibt ist alles gut. Nur bei sinnlosen Aussagen, wo die Leuts ihre Datagridse "füttern" und sowas - da werd ich kribblig.
Oder eben wenns doch Sinn ergibt, aber den verkehrten (Daten kommen aus Listboxen - das ist leider tatsächlich möglich - zumindest in WinForms, aber wer dem nachgeht, ist am Ende für Jahre auf finstersten Holzwegen unterwegs.)

---

Aber Klugscheissen hat noch niemandem geschadet:
Wir nehmen nicht den WorkCenter-Name zum Filtern, sondern den WorkCenter-Wert. Genauer: wir nehmen ein Objekt des Datentyps WorkCenter zum Filtern. Weil WorkCenter ist ein Enum, und ist somit ein Datentyp. Und WorkCenterTour auch. Und WorkCenterTour hat eine Property des Datentyps WorkCenter - daher kann man einer WorkCenterTour einen WorkCenter-Wert zuweisen.
Jo - und den nimmter dann zum Filtern - klar.

---

Achso - Begriffe sind wichtig: Was ist ein Datentyp, was ist ein Enum, was eine Auflistung, was ist ein Name, was ein Feld, Property, und und und.
Gugge diese Dinge hier: Grundlagen: Fachbegriffe und lies ausserdem ein gut Buch.

Jeiss schrieb:

dieses Theme abzuschließen

hohoho! - selten so gelacht!
im Ernst: Dassis ein ziemlich gutes Thema, und da kannste bestimmt noch jede Menge dran lernen.

ZB kannste genau jetzt den Umgang mittm ObjectBrowser lernen: VisualStudio richtig nutzen (Google ist nicht deine Mami)
Aber beachte genau den Video-Film, und auch alle Posts dazu, insbesondere, wie man den OB am günstigsten einstellt.
Wennde dir im OB die Properties von ListCollectionView anguckst, müssteste eiglich die Antwort finden.
Zumindest die zuständige Property.
Und wennde die Property hast, kannste vlt. erkennen, wie man die einsetzt. Zumindest kannste dann googeln für Code-Beispiele. Und sonst kannste immer noch hier fragen.

Ich hab jetzt nochmal geguckt - das ist 'ne wirklich gute Übung, zu lernen, wie man sich ins Framework und in die VisualStudio-Logik einarbeitet - auch son bischen Detectiv-Arbeit.

Jeiss schrieb:

Müsste ich nicht in den OB gelangen wenn ich, "ein Objekt" im Code-Editor anklicke, und dann im Kontextmenu auf "Go to definition F12" klicke?

ja, und sollte auch funktionieren. Guck nochma Video. Wenn man natürlich auf Schlüsselworte klickst, gibts da keine Definition von. Und wennde das ganze Wort selektierst, weissich auch nicht, obs geht.
jdfs. das is ganz wichtig, dass das geht.

---

Und das mitte SortDescription haste richtig rausgefunden.
Ja, ist bisserl umständlich. Man könnte sich aber auch eine Extension schreiben, wo man dann am Ende nur noch notiert:Wenn man sowas öfter braucht.

Ah - mir ist wieder eingefallen, warum das so umständlich ist: Normal ist der CollectionView-Kram als im Xaml zu formulieren vorgesehen, und da wäre das Code-Design recht praktisch (für Xaml-Verhältnisse normal praktisch).
Mein Umgang mit CollectionView ist da ja abweichend, dass ich die ins Viewmodel hole, um da codeseitig viele Möglichkeiten zu erhalten (etwa die Verwaltung des CurrentItem).

kennste?

ErfinderDesRades schrieb:

Mein Umgang mit CollectionView ist da ja abweichend, dass ich die ins Viewmodel hole,

Ne, mach ich auch so da viel flexibler. Man kann es auch im XAML formulieren, ist aber eher nur für die "statische" Anwendung gedacht oder wenn man mit CodeBehind arbeitet. Haste die CillectionView im ViewModel kann man damit eh schön Arbeiten. (Filtern, Sortieren, Gruppieren)

Es ist richtig das das SortDesciption Property der ICollectionView ReadOnly ist. Mann sollte ihr auch nur SortDescriptions hinzufügen oder wieder Removen.

Beispiel:


Was ICH gerne mache um hier auch IntelliSense und Compilerprüfung zu haben ist das ich das Property gerne mit NameOf(prop) angebe.

Man könnte auch einen IComparer implementieren:

Und dann Anwenden mit:


Das selbe gilt übrigens auch z.b. für das Gruppieren:


Ich hoffe ich konnte damit Helfen.

Grüße
Sascha

ja, das ist c#-Grütze.
Muss man mal rumfragen, ob vlt. ab 2017 diese Ob-Verknüpfung von MS demontiert wird. Ich weisses nicht, bis 2015 funzt das jdfs. noch.
Das wäre nervig, dann müssteste den OB immer öffnen, und mit Such-Eingaben arbeiten.

ErfinderDesRades schrieb:

Das wäre nervig, dann müssteste den OB immer öffnen, und mit Such-Eingaben arbeiten.

Ja, VS kann nun auch zum Code im .Net navigieren was ich gut finde.
Kann abgeschaltet werden, für jeder Sprache extra.
Hier ein Bild von den Optionen.



Grüße
Sascha