Trotz Backgroundworker hengt meine Aplikaiton

  • WPF

Es gibt 20 Antworten in diesem Thema. Der letzte Beitrag () ist von EugenIS.

    Trotz Backgroundworker hengt meine Aplikaiton

    Hallo Leute, und vielen Dank für's reinschauen.

    Kann es sein, dass ich etwas falsch verstehe... Hab eine WPF Aplikation und viele BGW's. Wollte die Stabilität ausprobieren. Die BGW's machen nichts anderes wie Zufällige Zahlen hochzählen.

    Leider hängt meine Anwendung dadurch. Gibt es eine Möglichkeit, die BGW's von Priorität der Bearbeitung so abzustuffen, dass die Anwendung immer reagiert?

    Danke im Voraus.

    Ohne Code wird da keiner eine Antwort drauf geben können.
    Es war einmal ein kleiner Bär... der wollte eine Geschichte hörn... Da erzählte ihm seine Mutti:
    Es war einmal ein kleiner Bär... der wollte eine Geschichte hörn... Da erzählte ihm seine Mutti:
    Es war einmal ein kleiner Bär... der wollte eine Geschichte hörn... Da erzählte ihm seine Mutti:
    ... Nun solltest es selber wissen. :'D

    EugenIS schrieb:

    viele BGW's
    sind ein NoGo. Falls Du in den Workern per Invoke() die GUI updatest, lass das mal sein.
    Ansonsten gugst Du ThreadPool.
    Falls Du diesen Code kopierst, achte auf die C&P-Bremse.
    Jede einzelne Zeile Deines Programms, die Du nicht explizit getestet hast, ist falsch :!:
    Ein guter .NET-Snippetkonverter (der ist verfügbar).
    Programmierfragen über PN / Konversation werden ignoriert!

    Was den Code angeht, kann leider dem schlecht hier rausstellen. der ist mitlerweile so riesig, dass ich selbst hier kaum durchblicke...

    Was die BGW's angeht, so habe ich um die 100 erstellt. Zu viel? Ich habe das Gefühl, dass wenn ich ein Thread schlafen lege (sprich mit sleep(100)) oder so, dann schläft mein ganzes system... Kann es sein, dass ich andere Methode dazu verwenden soll?

    Was den ThreadPool angeht, kann ich da ein BWG reinpacken? Wenn ja, hättest du kurzen Beispiel?

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

    100 Stück? Ich glaub ich kipp gleich vom Stuhl :0!

    Welche Methode man verwenden kann/sollte, könnte man besser abwägen, wenn wir wüssten was du bezwecken willst.
    Polling is trolling!

    Achtung: Ich habe die komische Angewohnheit, simple Dinge zu verkomplizieren..

    Ich kann mir beim besten Willen nicht vorstellen, wie man 100 BGWs brauchen kann. Nicht mal annähernd.
    »There's no need to "teach" atheism. It's the natural result of education without indoctrination.« — Ricky Gervais

    Tatsächlich braucht man in Wpf nicht einen einzigen BGW.
    BGW ist eine WinForms-Krücke, die eiglich bereits seit 2005 veraltet ist.
    Mit Veraltet meine ich, dass ein BGW keine typisierten Daten in den Nebenthread transferieren kann, und das ist numal seit 2005 Stand der Technik.
    Seit 2012 nutzt man übrigens den Async-Pattern, das ist ein ausserordentlich gut durchdachtes Threading-Konzept.

    nope, ein und die selbe Seite zeigt unter 2.0 folgendes:
    msdn.microsoft.com/en-us/library/ms228969(v=vs.80).aspx

    Es war lediglich nicht so breit implementiert wie heute.

    EugenIS schrieb:

    Was den Code angeht, kann leider dem schlecht hier rausstellen. der ist mitlerweile so riesig, dass ich selbst hier kaum durchblicke...
    Dann wärs mal dringend Zeit neu anzufangen. Ein Projekt, egal wie groß, muss durchschaubar / verständlich sein um Wartbarkeit zu gewährleisten.

    Dennoch wäre es generell mal interessant zu wissen, was du in diesen 100 BGWs so alles anstellst.

    ich wüsste jetzt aber auch nicht, was man da mit EAP rumzufuhrwerken hätte.
    EAP ist doch ein Architektur-Pattern, wenn man Bibliotheken entwickelt, die Methoden bereitstellen, darauf optimiert, asynchron aufgerufen zu werden.
    Wie ich den TE aber verstehe will er nur Methoden asynchron aufrufen - nicht neu entwickeln.
    Normal müsste reichen, er wrappert seine Aufrufe in ein Result = Await.Task.Run(Function()RufeDieMethodeFunc) und asynchron ist.

    Was die 100 BGW's angeht, so habe ich ein Datenbank-Controll gebaut, der jede Abfrage in ein Hintergrundprozess packt um die Oberfläche nicht zu belasten bei längerdauernden Abfragen. Somit wird ein BGW erstellt, fragt ab, und ruft eine CallBack methode auf, wenn er fertig ist. Ich dachte es würde meine Oberfläche entlasten...

    Angenommen ich würde es in Pattern reinpacken, wie würde es aussehen? Jemand ein Beispiel vielleicht?

    EugenIS schrieb:

    Was die 100 BGW's angeht, so habe ich ein Datenbank-Controll gebaut, der jede Abfrage in ein Hintergrundprozess packt um die Oberfläche nicht zu belasten bei längerdauernden Abfragen


    Async & Await
    KaskadekingDE on GitHub :)
    Bitte keine Fragen über Programmierung per PN! Dafür ist das Forum hier.

    Who cares? ¯\_(ツ)_/¯

    EDR hatte dir ja schon son ungefähres Beispiel gegeben, hier noch eins:
    (Inwiefern das Sinn ergibt mag dahergestellt sein, es geht sich um das Drumrum)
    Spoiler anzeigen

    VB.NET-Quellcode

    1. Public Class Form1
    3. Private Async Sub Form1_Load(sender As Object, e As EventArgs) Handles MyBase.Load
    4. Await Task.Run(Function() Wait())
    5. End Sub
    7. Public Function Wait() As Boolean
    8. For i As Integer = 0 To 10
    9. System.Threading.Thread.Sleep(1000)
    10. Me.Invoke(Sub()
    11. Me.Text = i.ToString()
    12. End Sub)
    13. Next
    14. Return True
    15. End Function
    16. End Class


    Aber ganz nebenbei gibt es dieses Asynchrone Task Gedöhns auch von Haus aus für die SQL-Geschichte, a la Await SQLConnection.OpenAsync()
    (Ich glaube in meinem oberen Beispiel ist das Invoken nur nötig, weil ich Threading.Thread.Sleep() nutze, da gäbe es zb. noch Await Task.Delay(1000), aber nur um es mal zu zeigen..)
    Polling is trolling!

    Achtung: Ich habe die komische Angewohnheit, simple Dinge zu verkomplizieren..

    Ich würde es gern ausprobieren, leider kriege ich es bis jetzt nicht in C# übersetzt...

    hab mir paar beispiel angesehen, steht überall das die Methode mit static async void blabla() anfengt,

    mein vs2010 kennt es nicht. async wird unterstrichen... fehlt mir irgend eine referenz?

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

    C#-Quellcode

    1. public Form1()
    2. {
    3. InitializeComponent();
    4. Action lAction = ((Action)macheEtwasAsynchron);
    5. lAction.BeginInvoke(endeAsynchroneAktion, lAction);
    6. }
    7. private void macheEtwasAsynchron()
    8. {
    9. for (int i = 0; i < 4000; i++)
    10. {
    11. Console.WriteLine(i);
    12. }
    13. }
    14. private void endeAsynchroneAktion(IAsyncResult pResult)
    15. {
    16. ((Action)(pResult.AsyncState)).EndInvoke(pResult);
    17. MessageBox.Show("Abgeschlossen");
    18. }


    Invoke macht deine Anwendung nicht langsam. Das war wohl eher so gemeint, wenn du Invoke bei einem Steuerelement aufrufst, wird der als parameter übergebene delegate im selben Thread des Steuerelements ausgeführt (was auch der GUI Thread ist) und wenn du jetzt in einer Schleife wie ich oben das machen würdest, würde die Form hängen weil die Prozedur am Ende im GUI Thread statt im neben Thread stattfinden würde.

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

    Ups hatte vergessen EndInvoke aufzurufen. Habs mal editiert.
    Um eine Eigenschaft von einem Steuerelement zu ändern musst du in den Code in dessen Thread ausführen (Control.Invoke(...)), dann friert aber halt die GUI ein wenn's zuviel ist.
    Parameter übergibst du in dem du die signatur der Methode änderst und das ganze in Action<t,t,..> castest statt Action.
    Dann kannst du bei aufruf von begininvoke die parameter übergeben.