Probleme beim ausführen des eigenen Programms

  • VB.NET
  • .NET (FX) 4.0

Es gibt 16 Antworten in diesem Thema. Der letzte Beitrag () ist von ErfinderDesRades.

    Probleme beim ausführen des eigenen Programms

    Hallo Liebe Community,

    aktuell stehe ich vor einem mir Unlogischem Problem. Solange ich mein Programm im Debug Modus ausführe, läuft das Projekt Stabil.
    Sobald ich jedoch die *exe ausführe zeigt mir der Task Manager nach einiger Zeit keine Rückmeldung.

    Ich konnte jetzt auch herausfinden, wann das Problem entsteht. Immer genau dann wenn das Datagridview(sichtbarer bereich) kpl. gefüllt ist.
    Das DGV ist über einen Dataview mit einer Datatable verbunden. Sobald ich eine neue Datarow hinzufüge, Refreshe ich mit diesem Befehl das DGV.

    VB.NET-Quellcode

    1. If Me.DGV_ActiveTradeTable.InvokeRequired Then
    2. Me.DGV_ActiveTradeTable.Invoke(Sub() Me.DGV_ActiveTradeTable.Refresh())
    3. Else
    4. Me.DGV_ActiveTradeTable.Refresh()
    5. End If


    ist das evtl. der Fehler?

    Gruß

    Rattenfänger schrieb:

    VB.NET-Quellcode

    1. Me.DGV_ActiveTradeTable.Invoke(Sub() Me.DGV_ActiveTradeTable.Refresh())
    Probierma Invoke auf die Form, nicht auf das DGV:

    VB.NET-Quellcode

    1. Me.Invoke(Sub() Me.DGV_ActiveTradeTable.Refresh())
    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!
    @Rattenfänger Sieh Dir mal den Unterschied zwischen .Refresh() und .Update() an.
    Das hat jetzt allerdings nix mit dem Invoke zu tun.
    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!
    @RodFromGermany also habe ich das jetzt richtig verstanden "Refresh" führt erst ein .Invalid() aus und danach ein .update() was zu Performance einbussen kommt und auch in den meisten fällen zu viel ist.
    Und nur das ausführen von .Update() das neu zeichnen vom steuerelement erzwingt und dazu Performanter ist?
    @Rattenfänger Ganz tief hab ich mich mit beiden Befehlen nicht befasst, das wollte ich Dir überlassen. ;)
    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!
    @Rattenfänger: Da jede Zeile ein eigenständiges Control ist, welches bei Bedarf selbst Invalidiert wird, benötigst du ein Refresh nur, wenn du Änderungen am Datagridview selbst vornimmst. Hier gibt es nur sehr wenige Änderungen die tatsächlich Invalidate() benötigen. Andernfalls reicht ein Update aus.

    Falls dein Problem damit nicht behoben ist, dann probiere den Inhalt deines Datatables in Objekte eine dafür erstellten Klasse zu übertragen und hau die in eine Bindinglist, die du dann über die Datasource an das Datagridview bindest. Spätestens dann kannst du dir das Refreshen komplett sparen.


    Ein Computer wird das tun, was du programmierst - nicht das, was du willst.
    @RodFromGermany werde mal schauen was ich noch selbst rausbekomme.
    Also den Code auszukommentieren hat geholfen, das Programm ist durchgelaufen. :thumbup:

    @Yanbel werde es die Tage mal mit .update testen. :thumbsup:

    wie @RodFromGermany und @Yanbel vorgeschlagen haben.

    VB.NET-Quellcode

    1. If Me.DGV_ActiveTradeTable.InvokeRequired Then
    2. Me.Invoke(Sub() Me.DGV_ActiveTradeTable.Update())
    3. Else
    4. Me.DGV_ActiveTradeTable.Update()
    5. End If
    @Rattenfänger Wenn das nicht ganz ultra zeitkritisch ist, kannst Du Deinen Code zu einem Einzeiler mutieren lassen, da passiert nix bei:

    VB.NET-Quellcode

    1. Me.Invoke(Sub() Me.DGV_ActiveTradeTable.Update())
    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!
    @RodFromGermany danke, für den Tipp.

    Also hier mal ein kleines Update.

    VB.NET-Quellcode

    1. Me.Invoke(Sub() Me.DGV_ActiveTradeTable.Refresh())


    funktioniert teilweise nicht, hier friert das Form ein, aber die Berechnungen werden fortgeführt.

    und jetzt teste ich das mal. :)

    VB.NET-Quellcode

    1. Me.Invoke(Sub() Me.DGV_ActiveTradeTable.Update())
    @Rattenfänger Wie viele Zellen sind denn in diesem DGV belegt?
    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!
    @RodFromGermany nicht viele grade mal 13 Columns, zeilen je nach größe der Form bis es keine Rückmeldung gibt.

    Der Fehler Tritt wirklich auf, wenn das ende der Form erreicht ist ???? Also keine der Update Formen hat geholfen :-(. Wer weiß wo ich den Bug drin hab.
    Was soll die Invokerei?
    Wird da iwas mit Threading gemacht?
    Wenn ja, warum sagt das keiner?
    Databinding funzt übrigens nicht, wenn nebenläufig die Daten manipuliert werden. Es gibt zwar keine InvalidOperationException wie normalerweise, wenn man nebenläufig ins Gui grabscht, aber funktionieren tuts trotzdem nicht.
    Ja, die daten werden im Backroundworker berechnet und in eine Datatabel eingetragen. die über ein Dataview mit dem DGV verbunden ist.
    Sorry mit dem BCKW, dachte das währe offensichtlich, wenn Invoke. :whistling: :/
    jo, also quasi minimal-invasiv wäre, BindingSource.RaiseListChangedEvents=False zu setzen, und nach Befüllung der angebundenen DataTable wieder auf True, und zusätzlich bs.ResetBindings().
    Ich empfehle den Async-Pattern - Backgroundworker war schon bei seiner Einführung Crap.
    codeproject.com/Articles/10296…ithout-any-additional-Lin
    @ErfinderDesRades

    Hmm, leider bin ich mit dem Async und Wait nicht klargekommen. Hatte mal ein Testexample durchgearbeitet, hat aber irgendwie nicht gefunzt !?!
    Na ja, dann werde ich da nochmal schauen müssen. Schaden wird's nicht :D .

    Ok, das der BCKW nicht so gut ist, habe ich schon gehört.
    Also für Prozesse(Sub) verstehe ich das, den nicht mehr zu benutzen. Aber was ist mit Forms, ist der dafür auch nicht geeignet, oder ist er nur für Forms geeignet(also eine Form mit dem BCK zu starten)?