CountryChooser(per flag)

  • WPF

Es gibt 62 Antworten in diesem Thema. Der letzte Beitrag () ist von asusdk.

    Guten Morgen,

    also seh ich richtig das du mir sagen willst ich soll auf ein Modell ansich verzichten ? Ich kann mir gut vorstellen das der Code dadurch wieder sehr viel schwieriger zu lesen sein wird, denn so wie bisher ist es ja schön aufgeteilt, oder meinst du damit ich soll aus dem zugrundeliegenden Modell einfach ein ViewModel machen ?


    Danke dir das du dir die Zeit nimmst mir da unter die arme zu greifen =)
    LG
    If Energy = Low Then
    Drink(aHugeCoffee)
    Else
    Drink(aHugeCoffeeToo)
    End If

    Jo - ich find den Code auch nicht schlecht. Und ein Model findet sich nicht darin - nur Viewmodels - allerdings teilweise unter dem falschem Ettiket "Model".
    Also ich will dir nicht sagen, du sollst auf ein Modell verzichten, sondern ich will dir klarmachen, dass du das bereits tust, und dass das ganz in Ordnung ist - mit Ausnahme der Ettikettierung.
    Oder welche Klasse in post#15 hälst du für ein Model?
    Ich sehe da nur Viewmodelse und Infrastruktur (in Form von Basisklassen).
    Irritierenderweise gibts zwei Basisklassen: BaseViewmodel und BaseModel, und beide sind Viewmodel-Infrastruktur, weil sie stellen INotifyPropertyChanged bereit zum Binden an ein View.

    ​Oder welche Klasse in post#15 hälst du für ein Model?

    Bis zu deiner vorherigen Erklärung, hielt ich das CountryModel für ein reines Model, aber du sagtest ja, das ein Model, das an die View gebunden wird, automatisch ein Viewmodel ist, daher ist wohl kein Model vorhanden, aber gesetzt dem Falle, das ich mit einem eigenen Model arbeiten wollen würde, dann müsste ich quasi das CountryModel lassen wie es ist, und noch ein Extra CountryViewModel erstellen, welches dieselben Propertys aufweist wie das CountryModel? Oder hab ich da was falsch verstanden? Und wenn ich richtig liege, wie würde ich das dann alles miteinander verbinden? Ich verstehe auf jeden Fall was du meinst, wenn du sagst, dann kann ich mir das Model sparen, aber evtl. hast du ja Zeit und Lust, ein ganz kleines Sampleprojekt zu erstellen, in dem das ganze wirklich mit Model, ViewModel, und View gelöst ist, so das ich evtl. verstehe wie das eigentlich aufgebaut sein sollte? Also wie gesagt nur, wenn du magst.

    LG und Danke
    If Energy = Low Then
    Drink(aHugeCoffee)
    Else
    Drink(aHugeCoffeeToo)
    End If

    Nee - bin ich der falsche für. IMO gibt das hier gegebene Problem es nicht her, da sinnvoll ein Model auszudifferenzieren, also könnte man logischerweise nur sinnlos eines ausdifferenzieren.
    Vermutlich kann man beim ausdifferenzieren auch noch viele Fehler machen, und selbst die perfekteste Lösung wäre immer noch: sinnlos, also ein Fehler.

    Aber @Nofear23m vertritt ja ein MVVM, wo zu jedem Viewmodel auch ein Model existiert soll. Und hat auch allerlei Sources hier auf VBP veröffentlicht.
    Vielleicht ist ja was dabei, wo er das auch umsetzt.

    Ein kleines Ausdifferenzierungs-Beispiel habich ja im Tut gegeben, gegen Ende post#1. Aber nur, um aufzuzeigen, dass es sinnlos ist, und nichts verbessert.

    asusdk schrieb:

    ein ganz kleines Sampleprojekt zu erstellen, in dem das ganze wirklich mit Model, ViewModel, und View gelöst ist, so das ich evtl. verstehe wie das eigentlich aufgebaut sein sollte?
    Noch einmal: IMO sollte es nicht so aufgebaut sein. Ebenso, wie du IDisposable nicht implementieren sollst (wo der Garbage-Collector seine Arbeit ja machen würde - solange du ihn nicht hinderst).
    Es existiert kein Problem, dann programmier um Himmels willen auch keine Lösung! Das ist ein Mega-grassierender Anti-Pattern - nichtexistente Probleme zu lösen. Und ist in mehrfacher Hinsicht verheerend.
    Google mal das Stichwort YAGNI.
    Und du scheinst mir da auch eine Neigung für zu haben, fast wie ein Süchtiger, der garnichts anderes denken kann.

    Ich fürchte, statt dein Projekt weiter zu vereinfachen (etwa die gedoppelte Basisklasse bereinigen), und Dinge korrekt zu ettikettieren, wirst du lieber iwo eine Vorlage suchen, die deine Sucht befriedigt, und Haufen Kram hinzubauen.
    Letztendlich hat dann der Anti-Pattern gesiegt, denn das Einfache ist dann verschwunden, wenn du damit fertig bist.
    Und in Zukunft steht dir dann nur noch eine überverkomplizierte Vorlage zur Verfügung, und pflanzt sich fort.

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von „ErfinderDesRades“ ()

    Ja ich bin gerade dabei das Projekt neu aufzuziehen, mit deinen vorgeschlagenen Anpassungen, aber eine Frage drängt sich mir noch auf, evtl. hilft die dabei mein Verständnis aufzumöbeln,
    gesetzt dem Fall das ich ein CountryViewmodel habe, aber ich habe z.B. ein UCL angelegt, welches "nur" Flagge und Name anzeigt, benötige ich dann dafür wieder ein eigenes Viewmodel, oder reicht es wenn ich das zu grunde liegende komplette CountryViewmodel verwende ?

    LG und Danke

    Nachtrag:
    Und eines erschließt sich mir leider auch noch immer nciht, wie setze ich bei den UCLs den DataContext ? Denn im Moment funktioniert es halt nicht das ich bereits zur Designtime Sehe wie das UCL aussehen sollte.
    If Energy = Low Then
    Drink(aHugeCoffee)
    Else
    Drink(aHugeCoffeeToo)
    End If

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von „asusdk“ ()

    asusdk schrieb:

    aber ich habe z.B. ein UCL angelegt, welches "nur" Flagge und Name anzeigt, benötige ich dann dafür wieder ein eigenes Viewmodel
    Wie schon vor langem gesagt: Flagge und Namen kannste per DataTemplate anzeigen.
    Aber generell: Wenn du ein View baust, und es gibt bereits geeignete Klassen, um daran zu binden, wäre es doch pures Gift und programmiertes Chaos, weitere Klassen anzulegen, odr?
    (Hättest du dir das nicht denken können?)

    asusdk schrieb:

    wie setze ich bei den UCLs den DataContext ?
    Mal eine Frage vorab: Hast du den SampleCode vom Grundlagen - MVVM-Anwendungs-Struktur - Tut mal downgeloadet und bei dir zum Laufen gebracht?

    Aber generell: Wenn du ein View baust, und es gibt bereits geeignete Klassen, um daran zu binden, wäre es doch pures Gift und programmiertes Chaos, weitere Klassen anzulegen, odr?(Hättest du dir das nicht denken können?)

    Ok, ja da hast du vollkommen recht, da hab ich wohl mal wieder zu komplioziert gedacht.
    Mal eine Frage vorab: Hast du den SampleCode vom Grundlagen - MVVM-Anwendungs-Struktur - Tut mal downgeloadet und bei dir zum Laufen gebracht?

    Ja ich habs gedownloadet, und es lässt sich auch starten, ich hab auch folgenden Codeteil gefunden:

    XML-Quellcode

    1. d:DataContext="{Binding Persons/, Source={StaticResource Mainmodel}}"


    aber selbst in angepasster Form,

    XML-Quellcode

    1. d:DataContext="{Binding AvailableCountrys, Source={StaticResource MainViewModel}}">


    meckert er lediglich das es kein MainViewModel gibt, aber das gibts definitiv, oder wolltest du auf was anderes hinaus ?

    Andere Variante:

    XML-Quellcode

    1. ​d:DataContext="{Binding AvailableCountrys, Source={x:Static MainViewModel}}">
    Da meckert er Das MainviewModel im Zieltyp nicht gefunden werden kann.
    If Energy = Low Then
    Drink(aHugeCoffee)
    Else
    Drink(aHugeCoffeeToo)
    End If

    1) Tja - Source={StaticResource MainViewModel} - das möchtest du wohl wissen, wo im Xaml das wohl hin-verweist?
    Also da steht ja: es muss eine Resource sein.
    Des Namens MainViewmodel - muss sich doch finden lassen in den Xaml-Files.
    Schau mal in Application.Xaml.
    Application.Xaml deshalb, weil das der höchste Punkt ist in der Anwendung, wo man etwas aufhängen kann.
    Die dort liegenden Resourcen sind in allen Views der Anwendung verfügbar.

    2) Seit einiger Zeit bin ich umgeschwenkt auf die andere Variante: Source={x:Static vm:MainViewModel.Instance}
    Das verweist nicht auf eine Resource (weil steht da ja nicht). Sondern verweist auf einen Datentyp:

    VB.NET-Quellcode

    1. vm:MainViewmodle
    .
    Und in diesem Datentyp auf ein statisches Feld (VB: Shared) namens Instance:

    VB.NET-Quellcode

    1. Public Shared Readonly Instance As New Mainmodel
    (Ich hoffe jdfs. dass das im Tut bereits drinne ist, und nicht nur bei meine Sources hier zuhause.)
    Ich gehe da übrigens noch einen Schritt weiter - schau genau (uclWorkspaceComboRated):

    XML-Quellcode

    1. DataContext="{Binding Source={x:Static vm:Mainmodel.Instance}}"

    Bereits zur Designzeit ist der DataContext damit auf den richtigen, endgültigen Wert festgelegt, der auch zur Laufzeit anzieht.
    Das Rumhampeln mit dem d:-xmlns kann ich mir sparen.

    Ich bevorzuge das mit der Static Instance, weil man damit gewährleisten kann, dass auch wirklich nur eine MainViewmodel-Instanz erzeugt wird.

    Dieser Beitrag wurde bereits 2 mal editiert, zuletzt von „ErfinderDesRades“ ()

    Ok, ich komm nicht mehr mit, wenn ich das verwende

    XML-Quellcode

    1. DataContext="{Binding Source={x:Static MainViewModel.Instance}}
    meckert er nur rum das MainviewModel in einem WPF-Projekt nicht unterstützt wird
    If Energy = Low Then
    Drink(aHugeCoffee)
    Else
    Drink(aHugeCoffeeToo)
    End If

    Da sagt er der NameSpacePräfix VM ist nicht definiert. Ich arbeite ja immer ohne namespaces um genau dieses verhalten zu vermeiden, daher verwende ich eigentlich alles als local (Verwende ich hier Local anstelle von VM, bleibt die fehlermeldung die gleiche)
    Ich vermute mal das da wieder an drölfzig stellen in der ganzen Anwendung sachen angepasst werden müssten damit das funktioniert, aber das ist mir wohl zu hoch, muss ich halt ohne Datacontext leben ^^
    If Energy = Low Then
    Drink(aHugeCoffee)
    Else
    Drink(aHugeCoffeeToo)
    End If

    Ich hab dein project ja offen, aber ich finde nirgends eine Definition von VM, in der Application.xaml ist ein NameSpace My, definiert, aber ich finde absolut nichts zu den von dir erwähnten NameSpaces, auch verwendest du in dem PersonListProject noch die "ältere" Methode, ich will ja nicht aufgeben, aber ich verstehe nicht was genau du mir zu sagen versuchst....
    If Energy = Low Then
    Drink(aHugeCoffee)
    Else
    Drink(aHugeCoffeeToo)
    End If

    XML-Quellcode

    1. <UserControl x:Class="CountryFlagChooser"
    2. xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
    3. xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
    4. xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006"
    5. xmlns:d="http://schemas.microsoft.com/expression/blend/2008"
    6. xmlns:local="clr-namespace:CountryChooser2"
    7. mc:Ignorable="d"
    8. VisualTextRenderingMode="ClearType"
    9. RenderOptions.BitmapScalingMode="Fant"
    10. BorderBrush="Black"
    11. Background="Transparent"
    12. BorderThickness="0,1,0,1"
    13. DataContext="{Binding Source={x:Static MainViewModel.Instance}}">
    15. <Viewbox>
    16. <ListBox ItemsSource="{Binding AvailableCountrys}"
    17. BorderBrush="Black"
    18. SelectedItem="{Binding SelectedCountry}"
    19. Background="Transparent">
    23. <ListBox.ItemsPanel>
    24. <ItemsPanelTemplate>
    25. <StackPanel Orientation="Horizontal"/>
    26. </ItemsPanelTemplate>
    27. </ListBox.ItemsPanel>
    31. </ListBox>
    33. </Viewbox>
    34. </UserControl>



    da meckert er bereits bei: DataContext="{Binding Source={x:Static MainViewModel.Instance}}">
    das MainViewModel von WPF nicht unterstützt wird.

    DatenContext setzen ist in WPF schon immer sehr schwierig bis hin zu absolut nicht begreifbar für mich, daher bin ich meist schon froh, wenn die Anwendung überhaupt funktioniert, Das im Designer nichts so aussieht, wie in der fertigen Anwendung, ist etwas mit dem ich bisher immer leben musste ^^


    Nachtrag: @ErfinderDesRades


    Ich hab jetzt im UCL den Context so gebunden: DataContext="{Binding AvailableCountrys, Source={StaticResource Mainmodel}}" in der Application.xaml hab ich "<local:MainViewModel x:Key="Mainmodel"/>", es wird kein Fehler mehr angezeigt, aber das Aussehen des UCL im Designer ändert sich nicht, und dafür funktioniert es im Betrieb garnicht mehr, nehm ich den Context wieder weg, funktioniert es zumindest wieder

    MainWindow wenn DataContext gesetzt:


    Ohne DataContext:



    Nachtrag2:

    ich hab jetzt nochmal bei @Nofear23m ´s tutorial nachgesehen und folgendes gefunden:

    d:DataContext="{d:DesignInstance IsDesignTimeCreatable=True,Type={x:Type local:MainViewModel}}"

    Damit scheint jetzt auch im designer direkt angezeigt zu werden was ich sehen möchte, also das CountryChooserUCL hat jetzt schon die Einträge der Daten im Mainviewmodel, nur die Bilder werden nach wie vor nicht geladen, ich steht wohl irgendwo massiv auf dem Schlauch. Kann der Designer denn die Bilder aus den Assets, die per URI-Property im ConutryViewmodel hinterlegt sind nicht in der Designtime anzeigen ?
    If Energy = Low Then
    Drink(aHugeCoffee)
    Else
    Drink(aHugeCoffeeToo)
    End If

    Dieser Beitrag wurde bereits 4 mal editiert, zuletzt von „asusdk“ ()

    asusdk schrieb:

    ich finde nirgends eine Definition von VM, in der Application.xaml ist ein NameSpace My, definiert, aber ich finde absolut nichts zu den von dir erwähnten NameSpaces
    jo - haste recht - in dem Tut nenne ich den lokalen Namespace my.
    Andere - die lieber längere Bezeichner haben (dafür aber weniger missverständlich), würden an der Stelle wohl local schreiben.

    Ok - soweit biste ja schon.
    Ich werds auch langsam müde. V.a., dass nun deine Runtime kaputt ist, deutet auf ein Querschiessen verschiedener Ansätze hin.

    Kannst du dein Projekt nicht einfach anhängen, und ich guck, ob ichs eingefrickelt kriege?

    Ah - ich glaub ich seh's:

    XML-Quellcode

    1. DataContext="{Binding Source={x:Static MainViewModel.Instance}}"
    Das ist tatsächlich ein Gemisch beider Varianten

    Variante 1 (Bindung an ein Objekt in den Resourcen von Application.Xaml) müsste heissen:

    XML-Quellcode

    1. DataContext="{Binding Source={StaticResource MainViewModel}}"
    da ist kein xmlns anzugeben, weil MainViewModel ist der Name eines Objekts.

    Variante 2 (Bindung an ein statisches Feld in einem Datentyp) müsste heissen:

    XML-Quellcode

    1. DataContext="{Binding Source={x:Static local:MainViewModel.Instance}}"
    da ist der xmlns anzugeben, weil local:MainViewModel ist ein Datentyp, und muss (mithilfe des xmlns) vollqualifiziert angegeben werden.
    Und das genannte Public Shared Readonly Field Instance sollte da sein und instanziert.

    Also x:Static != StaticResource

    Dieser Beitrag wurde bereits 5 mal editiert, zuletzt von „ErfinderDesRades“ ()

    Hi @ErfinderDesRades

    Ich habs nun so eingetragen: d:DataContext="{d:DesignInstance IsDesignTimeCreatable=True,Type={x:Type local:MainViewModel}} und das läuft fast einwandfrei, ohne das ich etwas in der Application.xaml benötige, auch muss ich keine InstanceProperty erstellen (fals das mitr statisches Feld gemeint war ?)
    Das UCL zeigt mir nun auch Quasi die Einträge an die ich ja im MainViewModel erstelle, nur die Bilder werden im Designer nach wie vor nicht angezeigt, und hier beschleicht mich der Verdacht das es nicht am Datencontext liegt, ich häng das Proljekt später mal an, muss nur grad einiges für die Arbeit erledigen.

    LG und Danke dir =)
    If Energy = Low Then
    Drink(aHugeCoffee)
    Else
    Drink(aHugeCoffeeToo)
    End If

    ne, du meintest doch das ich das lassen soll, daher ist der Datacontext im Mainwindow in die Xaml gewandert

    XML-Quellcode

    1. ​<Window.DataContext>
    2. <local:MainViewModel/>
    3. </Window.DataContext>
    If Energy = Low Then
    Drink(aHugeCoffee)
    Else
    Drink(aHugeCoffeeToo)
    End If

Facebook
Telefonspende