Control Refresh im Codebehind

  • WPF

Es gibt 6 Antworten in diesem Thema. Der letzte Beitrag () ist von Andromeda.

    Control Refresh im Codebehind

    Hallo Alle,
    Simples XAML

    XML-Quellcode

    1. <StackPanel>
    2. <WrapPanel Name="wrap" Visibility="Collapsed">
    3. <Label Content="Ausgabe"/>
    4. <TextBlock Name="tblBlock" Text="Hierhin" FontSize="14pt"/>
    6. </WrapPanel>
    7. <Button Content="Machwas" Name="cmdWrap" Width="60" ></Button>
    8. </StackPanel>

    Beispielcode natürlich nicht funktionierend

    VB.NET-Quellcode

    1. Private Sub cmdWrap_Click(sender As Object, e As RoutedEventArgs) Handles cmdWrap.Click
    2. wrap.Visibility = Visibility.Visible
    3. For i = 1 To 10
    4. tblBlock.Text = i.ToString
    5. ' Weiterer Code
    6. Threading.Thread.Sleep(500)
    7. Next
    8. wrap.Visibility = Visibility.Collapsed
    9. End Sub


    Ich habe schon verschiedene Sachen z.B. Backgroundworker getestet, aber überall wird die Konrolle an das WPF übergeben.
    Gut, man kann den Dialog disablen, man kann im Closing das abfangen aber elegant ist das alles nicht.

    Gibt es irgendeine Möglichkeit nur das wrappanel sichtbar zu machen und den textblock zu aktualisieren?
    Meine Experimente mit dem Dispatcher.BeginInvoke waren da auch nicht glücklich.

    (Für längere Aktualsierungen habe ich einen Wait Dialog gebastelt, aber das ist auch nicht immer das gelbe vom Ei für so eine simple Sache)

    Framework 4.5.1

    Gruß aus dem Weltall und vielen Dank

    Das Problem habe ich doch beschrieben.
    Ich hätte gerne eine Methode, mit welcher ich die Sichtbarkeit eines Elementes in einer Prozedur und den Wert eines Elementes in einer Schleife ändern kann und die Elemente aktualisiert werden ohne die Steuerung an das Fenster zu geben.

    Wenn es so Pille Palle ist, bin ich ja dankbar für den entsprechenden Beispielcode und entschuldige mich für meine Dämlichkeit.

    ich hab nix von PillePalle gesagt, ich hab nur keine Problembeschreibung vorgefunden.
    Auf deim Ansatz wüsste ich jetzt auch keine Lösung aufzubauen.
    Ich verwende Wpf immer im Zusammenhang mittm MVVM-Pattern - also Sichtbarkeit und Werte von Elementen wird per Databinding gesteuert.

    Mir ist auch nicht klar, was "Steuerung an das Fenster zu geben" bedeutet.
    Wenn du damit Threading meinst - da gibts eiglich keine Alternative: Gui-Elemente müssen im Gui-Thread manipuliert werden.

    Ah - vlt kann ich doch helfen:
    Wenn du eine Methode hast, die lange dauert, viele Daten verarbeitet - aber nicht ins Gui grabscht! - , dann kann ich dir zeigen, wie man die mit Async/Await nebenläufig macht, sodass das Gui sie aufrufen kann , ohne deshalb zu blockieren.

    Auch ich setze Werte und Sichtbarkeit in der Regel per Binding aber hier macht das keinen Unterschied, da auch beim Binding das Element erst am Ende der Prozedur neu gezeichnet wird (solange im selben Thread)

    Async/Await sollte sich m.E. ähnlich verhalten wie der Backgroundworker oder irre ich mich da.

    D.h. der Code wird Asynchron ausgeführt - in einem anderen Thread - und kann dadurch auf dem Gui neu gezeichnet werden.
    Der Nachteil bei all diesen Methoden ist ganz einfach, dass das GUI für Input offen bleibt (was in der Regel ja gewünscht ist, um umfangreiche Aktionen laufen lassen zu können und trotzdem auf Usereingaben zu reagieren)
    Es geht einfach um das Forcieren von Neuzeichnen eines Elementes. In WinForms gab es zumindest für Labels und Frames ein Refresh oder Repaint.
    Es nervt ganz einfach, dass nach gefühlten 1000 Versionen von .net es immer noch keine simple Methode gibt, einen Fortschritt zu visualisieren ohne gleich ein Fass aufzumachen.

    Ich bleibe bei meinem Projekt nun dabei, für all diese Sachen meinen Wartendialog (Hier lasse ich den Code in einem anderen Thread laufen und kicke nur Aktualisierungen im Dialog an. Der Dialog selbst ist von allen Nutzereingaben entsorgt. ) vorzuschalten, ist zwar aufwendiger aber es funktioniert wenigstens.
    Solange, bis ich nicht was besseres finde.

    Andromeda schrieb:

    Async/Await sollte sich m.E. ähnlich verhalten wie der Backgroundworker oder irre ich mich da.
    Stimmt - nur Async/Await ist aus verschiedenen Gründen besser: Man muss keine WinForms.dll dazu laden, man kann richtig typisierte Daten übergeben, man kann mehr straight forward coden.
    Aber scheints willst du lieber beim BGW bleiben.

    Andromeda schrieb:

    Es nervt ganz einfach, dass nach gefühlten 1000 Versionen von .net es immer noch keine simple Methode gibt, einen Fortschritt zu visualisieren ohne gleich ein Fass aufzumachen.
    Ist richtig - Threading ist immer noch nicht einfach, und insbesondere mit Fortschritts-Anzeige nicht.

Facebook
Telefonspende