Ressourcenauslagerung vom MainWindow in die Application.XAML führt zu Bindungsproblem bei StaticResource

  • WPF

Es gibt 17 Antworten in diesem Thema. Der letzte Beitrag () ist von VaporiZed.

    Ressourcenauslagerung vom MainWindow in die Application.XAML führt zu Bindungsproblem bei StaticResource

    Hallo zusammen.

    Ich habe in einem ResourceDictionary ("Ressourcennachschlagewerk") einige Vektorgrafik-Icons. Wenn ich diese in MainWindow einbinde, funktioniert folgender XAML-Code:

    XML-Quellcode

    1. <Window.Resources>
    2. <ResourceDictionary Source="ResourceDictionary.xaml"/>
    3. </Window.Resources>
    5. <Menu VerticalAlignment="Top" Background="White">
    6. <MenuItem Header="{StaticResource GoToCheckPoint}" ToolTip="gehe zu Checkpoint"/>
    7. <MenuItem Header="{StaticResource GoToConfigurationSite}" ToolTip="gehe zur Konfigurationsseite des Checkpoints"/>
    8. </Menu>

    Verschiebe ich den Ressourcenverweis in die Application.XAML, egal, ob mit

    XML-Quellcode

    1. <Application.Resources>
    2. <ResourceDictionary Source="ResourceDictionary.xaml"/>
    3. </Application.Resources>

    oder

    XML-Quellcode

    1. <Application.Resources>
    2. <ResourceDictionary>
    3. <ResourceDictionary.MergedDictionaries>
    4. <ResourceDictionary Source="ResourceDictionary.xaml"/>
    5. </ResourceDictionary.MergedDictionaries>
    6. </ResourceDictionary>
    7. </Application.Resources>

    erhalte ich bei den StaticResouce-Stellen die Fehlermeldung: "Bei dem angegebenen Element handelt es sich bereits um das logische untergeordnete Element eines anderen Elements. Führen Sie zuerst eine Trennung durch."

    Welcher Denkfehler hat mich hier im Griff?
    Dieser Beitrag wurde bereits 5 mal editiert, zuletzt von „VaporiZed“, mal wieder aus Grammatikgründen.

    Aufgrund spontaner Selbsteintrübung sind all meine Glaskugeln beim Hersteller. Lasst mich daher bitte nicht den Spekulatiusbackmodus wechseln.

    Hallo

    Der letzte Schnipsel sollte so passen. Haste die selbe Resource nochmal wo gemerged?
    Sollte so hinhauen.


    Grüße
    Sascha
    If _work = worktype.hard Then Me.Drink(Coffee)
    Seht euch auch meine Tutorialreihe <WPF Lernen/> an oder abonniert meinen YouTube Kanal.

    ## Bitte markiere einen Thread als "Erledigt" wenn deine Frage beantwortet wurde. ##

    Sehr merkwürdig. Ändere ich in der Application.XAML das Snippet von MergeDictionaries zum quasi SingleDictionary (also Post#1-Snippet#3 zu Post#1-Snippet#2), wird es für den Moment richtig im Designer angezeigt. Wenn ich das Projekt kompiliere, ist's aber wieder aus.
    Projekt anbei.
    Dateien

    • WpfApp1.zip

      (4,65 kB, 65 mal heruntergeladen, zuletzt: )
    Dieser Beitrag wurde bereits 5 mal editiert, zuletzt von „VaporiZed“, mal wieder aus Grammatikgründen.

    Aufgrund spontaner Selbsteintrübung sind all meine Glaskugeln beim Hersteller. Lasst mich daher bitte nicht den Spekulatiusbackmodus wechseln.

    Hallo

    Dein Projekt kompiliert (unter .Net 5.0 - 6.0 habe ich hier auf der Arbeit nicht) ganz normal. Evtl. ein Bug des RC.
    Ich würde (noch) auf 5.0 bleiben.

    Alternativ kannst du folgendes versuchen:

    XML-Quellcode

    1. ​
    2. <Application.Resources>
    3. <ResourceDictionary>
    4. <ResourceDictionary.MergedDictionaries>
    5. <ResourceDictionary Source="ResourceDictionary.xaml"/>
    6. </ResourceDictionary.MergedDictionaries>
    8. <Style TargetType="Rectangle">
    9. <Setter Property="Fill" Value="Transparent"></Setter>
    10. </Style>
    11. </ResourceDictionary>
    12. </Application.Resources>


    Erfahrungsgemäß kommt es immer wieder zu komischen Fehlern wenn in der Application.xaml kein Style festgelegt ist.

    Grüße
    Sascha
    If _work = worktype.hard Then Me.Drink(Coffee)
    Seht euch auch meine Tutorialreihe <WPF Lernen/> an oder abonniert meinen YouTube Kanal.

    ## Bitte markiere einen Thread als "Erledigt" wenn deine Frage beantwortet wurde. ##

    Also es liegt wohl an VS 2022 (17.0.0). Das Umschalten auf .NET 5 gab keine Besserung. Der gleiche XAML-Code liefert in VS 2019 unter .NET Framework keine Probleme. Und da ich nun wohl Dank der Parallelinstallation der beiden Visual Studios in VS 2019 keine WPF-.NET-Projekte mehr erstellen kann, bin ich erstmal am Ar…gen mit Mikrosaft :cursing:
    Dieser Beitrag wurde bereits 5 mal editiert, zuletzt von „VaporiZed“, mal wieder aus Grammatikgründen.

    Aufgrund spontaner Selbsteintrübung sind all meine Glaskugeln beim Hersteller. Lasst mich daher bitte nicht den Spekulatiusbackmodus wechseln.

    Und unter der 2022er mit .Net 5.0?
    Ich Arbeite auch daheim nich mit der 2019er, die 2022 hat mir nich zu viele Bugs und läuft gerade mit Asp.Net Core im Debugging viel zu langsam.

    Ist alles noch recht verbuggt. 2019 mit .Net 5 läuft super und kann jederzeit hoch auf .Net 6 da es ja wenig BreakingChanges gibt, deshalb ist man denke ich gut beraten wenn man noch etwas wartet.

    Grüße
    Sascha
    If _work = worktype.hard Then Me.Drink(Coffee)
    Seht euch auch meine Tutorialreihe <WPF Lernen/> an oder abonniert meinen YouTube Kanal.

    ## Bitte markiere einen Thread als "Erledigt" wenn deine Frage beantwortet wurde. ##

    Nofear23m schrieb:

    Und unter der 2022er mit .Net 5.0?
    Wie gesagt:

    VaporiZed schrieb:

    Das Umschalten auf .NET 5 gab keine Besserung.

    Nofear23m schrieb:

    Ich Arbeite auch daheim nich mit der 2019er, die 2022 hat mir nich zu viele Bugs
    Was so ein doppelter Typo Einfluss auf die Aussagekraft hat ;) . Bis ich gemerkt habe, dass Du jeweils "noch" schreiben wolltest, musste ich es 3x lesen :P
    Naja, ich versuch demnächst erstmal 2019 wieder richtig zum Funktionieren zu bekommen, dann berichte ich wieder. Und ich mach n Ticket bei Mikrosaft auf.
    Dieser Beitrag wurde bereits 5 mal editiert, zuletzt von „VaporiZed“, mal wieder aus Grammatikgründen.

    Aufgrund spontaner Selbsteintrübung sind all meine Glaskugeln beim Hersteller. Lasst mich daher bitte nicht den Spekulatiusbackmodus wechseln.

    Sorry, war gestern Abend noch mit dem Handy getippt.

    Grüße
    If _work = worktype.hard Then Me.Drink(Coffee)
    Seht euch auch meine Tutorialreihe <WPF Lernen/> an oder abonniert meinen YouTube Kanal.

    ## Bitte markiere einen Thread als "Erledigt" wenn deine Frage beantwortet wurde. ##

    Ich musste auch genauer lesen. ;)
    Ich verstehe das mit der Parallelinstallation gerade nicht. Wie darf ich mir das vorstellen? Du hast das Studio in Version 2019 und 2022 installiert. Also 2 getrennte Studios, und das 2019 hat nun Einschränkungen?
    Rechtschreibfehler betonen den künstlerischen Charakter des Autors.

    Akanel schrieb:

    Du hast das Studio in Version 2019 und 2022 installiert. Also 2 getrennte Studios, und das 2019 hat nun Einschränkungen?
    Korrekt. .NET-Projekte sind jetzt erstmal in VS2019 für mich unzugänglich.

    Amro schrieb:

    versuch mal die ".vs" zu löschen im Projektordner.
    Bringt weder für das Ursprungsproblem noch für das VS2019-.NET-Problem eine Besserung (weiß auch nicht, worauf der Vorschlag abgezielt hat)

    ##########

    @Nofear23m (Ich bin mal so dreist und pinge Dich mal nur an): Es wird etwas unerklärlicher für mich.
    Wenn Ich abändere auf

    XML-Quellcode

    1. <MenuItem Header="{StaticResource GoToCheckPoint}" ToolTip="gehe zu Checkpoint">Foo</MenuItem>
    , kompiliere und Projekt neu lade, ist es ok. Wenn ich auf die Kurzschreibweise zurückgehe nicht. WTF?!?

    ##########

    Ich konnte jetzt eine Besonderheit noch finden: Wenn ich im MainWindowKopf das hier rausnehme, geht es in VS2022:

    XML-Quellcode

    1. d:DataContext="{d:DesignInstance IsDesignTimeCreatable=True,Type={x:Type local:MainWindow}}"

    Alternativ IsDesignTimeCreatable auf False stellen und kompilieren. Ich blick's nicht …
    Dieser Beitrag wurde bereits 5 mal editiert, zuletzt von „VaporiZed“, mal wieder aus Grammatikgründen.

    Aufgrund spontaner Selbsteintrübung sind all meine Glaskugeln beim Hersteller. Lasst mich daher bitte nicht den Spekulatiusbackmodus wechseln.

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

    VaporiZed schrieb:

    Wenn ich auf die Kurzschreibweise zurückgehe nicht.

    Definiere bitte kurz die "Kurzschreibweise". Kenne mich gerade nicht aus ?(

    VaporiZed schrieb:

    Wenn ich im MainWindowKopf das hier rausnehme

    Ja, das zickt aber so gut wie immer rum. Der DesignTime-DataContext ist überhaupt nicht dafür gemacht.

    Was im Hintergrund passiert ist das eine Instanz der Klasse erstellt wird. (Es wird der Parameterlose Konstruktor aufgerufen) Da die KLasse von Window erbt ist das natürlich doof und der Designer kommt hier ins schwanken.
    Das klappte nie so richtig. Deshalb sollte man eben auch mit ViewModel-Klassen arbeiten und nicht mit der CodeBehind. Immer auf eine Klasse binden. Das ist ganz wichtig. Du tust dir ja auch schwer eine Basisklasse zu definieren um INotifyPropertyChanged sauber reinzubekommen, du müsstest also in jeder CodeBehind immer wieder das Interface implementieren, macht also sowieso keinen Spass.

    Grüße
    Sascha
    If _work = worktype.hard Then Me.Drink(Coffee)
    Seht euch auch meine Tutorialreihe <WPF Lernen/> an oder abonniert meinen YouTube Kanal.

    ## Bitte markiere einen Thread als "Erledigt" wenn deine Frage beantwortet wurde. ##

    Nofear23m schrieb:

    Definiere bitte kurz die "Kurzschreibweise"
    Da fehlt(e) mir der Fachbegriff. Also ausführlich wäre mit Start- und Endtag (<Foo>…</Foo>) und Kurzschreibweise eben nur <Foo />.

    Nofear23m schrieb:

    Da die KLasse von Window erbt ist das natürlich doof und der Designer kommt hier ins schwanken. Das klappte nie so richtig. Deshalb sollte man eben auch mit ViewModel-Klassen arbeiten und nicht mit der CodeBehind.
    Das mit dem Schwanken und nie so richtig klappen, versteh ich als WPF-Laie noch nicht, ich hatte das mit d:DataContext= und Bezug auf MainWindow erstmal nur aus Deinen ersten Tutorial-Videos übernommen. Aber klingt wie: Nicht Window mittels DataContext implizit instanziieren, sondern andere Klassen, also wenn man ein UserControl hat, dann da das zugehörige ViewModel. Ist hoffentlich richtig laieninterpretiert.
    Nebenbei: Ich hatte noch gar kein CodeBehind, außer Class MainWindow … End Class

    Nofear23m schrieb:

    Du tust dir ja auch schwer eine Basisklasse zu definieren um INotifyPropertyChanged sauber reinzubekommen, du müsstest also in jeder CodeBehind immer wieder das Interface implementieren, macht also sowieso keinen Spass.
    Ehh, keine Ahnung. Heißt das jetzt, ich sollte ne Basisklasse mit INotifyPropertyChanged anlegen (ViewModelBase) oder eben nicht ?( . Ich hatte aus den Tuts rausgehört: Ja, sollte man. Und eben nicht überall INotifyPropertyChanged einzeln implementieren. Aber da versteh ich jetzt nicht ganz, in welche Richtung eben Dein Abschlusssatz zielt.
    Dieser Beitrag wurde bereits 5 mal editiert, zuletzt von „VaporiZed“, mal wieder aus Grammatikgründen.

    Aufgrund spontaner Selbsteintrübung sind all meine Glaskugeln beim Hersteller. Lasst mich daher bitte nicht den Spekulatiusbackmodus wechseln.

    Sorry, nur noch am Handy.

    Zum DesignTime DataContext, damit meine ich das DesignTime-seitig hier das mit dem DataContext etwas holprig funktioniert. War schon immer so, egal ob da Code drinnen ist. Also ne ViewModel Klasse zum Binden verwenden.

    Zum letzteren Teil. Ja, man soll unbedingt eine Basisklasse haben welche das Interface implementiert, und genau das funzt in der CodeBehind eines Window oder eines UserControls eben nicht, das ist ja auch der Grund warum man auf eine ViewModel-Klasse bindet und nicht direkt auf das CodeBehind-File.

    In den Tutorials ist es Teilweise so da hier ja von MVVM noch keine rede ist und hier oft der einfachheit halber auf die CodeBehind gebunden wurde, manchesmal hald.

    Hoffe das war verständlich sonst hole ich gerne nochmal aus.

    Grüße
    Sascha
    If _work = worktype.hard Then Me.Drink(Coffee)
    Seht euch auch meine Tutorialreihe <WPF Lernen/> an oder abonniert meinen YouTube Kanal.

    ## Bitte markiere einen Thread als "Erledigt" wenn deine Frage beantwortet wurde. ##

    Ich hatte gestern auch Probleme nach der Installation von der .Net 5 Variante. Ich habe daraufhin das SDK nochmal neu installiert und anschließend bei VS19 nochmal ein Update über den Installer laufen lassen. Seitdem sind die Probleme weg. Vielleicht hilft dir das ja auch, um bei VS19 deine .NET-Funktionalität wiederherzustellen

    Das hatte ich auch festgestellt. Nach dem VS2019-Update auf 16.11.7 ging es wieder. .NET6 wurde aber als Einstellmöglichkeit entfernt. In VS2022 ist es immer noch zugänglich.
    Dieser Beitrag wurde bereits 5 mal editiert, zuletzt von „VaporiZed“, mal wieder aus Grammatikgründen.

    Aufgrund spontaner Selbsteintrübung sind all meine Glaskugeln beim Hersteller. Lasst mich daher bitte nicht den Spekulatiusbackmodus wechseln.

    Meines Wissens nach geht .Net 6 doch nur mit der 2022er. Oder?

    Insofern ist das ja richtig so.
    If _work = worktype.hard Then Me.Drink(Coffee)
    Seht euch auch meine Tutorialreihe <WPF Lernen/> an oder abonniert meinen YouTube Kanal.

    ## Bitte markiere einen Thread als "Erledigt" wenn deine Frage beantwortet wurde. ##

    Jop, aber m.E. wurde es bis VS2019 16.11.6 noch als … »expermientell«? Nee, aber irgendwie so mit angeboten. Auf jeden Fall geht jetzt wieder .NET 5 in VS2019 trotz 22er-Parallelinstallation.
    Dieser Beitrag wurde bereits 5 mal editiert, zuletzt von „VaporiZed“, mal wieder aus Grammatikgründen.

    Aufgrund spontaner Selbsteintrübung sind all meine Glaskugeln beim Hersteller. Lasst mich daher bitte nicht den Spekulatiusbackmodus wechseln.

Facebook
Telefonspende