Suchergebnisse

Wie soll es bei deinem Code vorkommen das dies geschieht? Läuft doch alles im selben Thread. Aber wenn du Multithreading anwendest, könnte das mit dem Flagge rauf und runter in die Hose gehen. Du kannst aber einen lock nutzen(SyncLock in VB), dann ist das auch ThreadSafe(wenn ich mich jetzt nicht irre). VB.NET-Quellcode (41 Zeilen) Also schau mal bei MS in der Doku für weitere Details.

Du kannst ja nicht feststellen, wann das Display das update durch hat. Das macht es schwierig was vernünftiges zu machen. Evtl. kann man das berechnen. Wenn das Display z.B. 1 Sekunde braucht um alle Pinne einmal umzuschalten, würde ich einfach nur 1 mal pro Sekunde zum Display senden, wenn denn was zum senden da ist. Der Timer tickt dann regelmäßig, wenn der Buffer nicht nothing ist wird gesendet, nach dem senden den buffer wieder löschen. Ich denke das ist so auch schonender für das Display, w…

Mein Vorschalg mit dem Timer ist sehr leicht umsetzbar. Dazu kannst du auch eine TrackBar nutzen, so das der User selbst die Updategeschwindigkeit der Zeilen/Displays einstellen kann. Wenn bei dir bei 2 Modellen solche unterschiede Vorhanden sind, wird das auch bei deinen Usern so einige Unterschiede geben, von Schildköten bis zu Geparden was die Geschwindigkeit angeht, daher denke ich das das durchaus Sinn machen kann. Aber schau dir an was der ErfinderDesRades noch sagen wird, ich wäre fast be…

Ja Synclock wird hier nichts nutzen, ich denke das Problem ist einfach das der Sendevoorgang schneller von statten geht, als das Update des Displays selbst. Deshalb denke ich das das IDLE-Event möglicherweise auch nichts bringt. Ich kenne das auch von MCUs(Mikrokontrollern), die Daten sind ratz fatz gesendet, passiert aber auf der MCU nach dem Lesevorgang weiteres, kann die MCU solange nicht lesen(ausser man hat das entsprechend programmiert und auf der MCU wird der Vorgang abgebrochen, wenn Dat…

Nein, wie du dir das vorstellst wird das nichts. Dein Problem ist auch ein anderes, genau das habe ich im meinem letzten Post beschrieben. Deine Geräte sind einfach nicht bereit zu lesen wenn sie noch am Updaten sind, solange das Gerät updated kann deine App nicht senden, will aber und muss warten(Thread blockiert) bis ein Timeout erreicht wird oder die Geräte lesen können, dadurch wird deine App ruckelig. Um das anständig zu verbessern, bleibt nur Async oder Threading, wobei dann immer nur die …

Zitat von tron25: „Wird ein SyncLock-Abschnitt nachgeholt, wenn er beim letzten Versuch gesperrt war?“ Zitat von tron25: „Ich habe mir die Definition von "SyncLock" angeschaut. Allerdings bin ich mir nicht sicher, ob diese Funktion mir nützt.“ Aha, hast du aber nicht wirklich verinnerlicht, sonst wüsstest du das. Ich denke du hast mein Beispiel entweder nicht oder nicht richtig getestet, denn die Debug-Ausgabe hätte das deutlich gemacht. Nun haben dir hier 2 Leute gesagt, SyncLock ist hier nicht…

Wenn das Display nicht mehr hinterherkommt, sende weniger. So einfach ist das, das was du da machen willst, wäre wie wenn du beim spielen V-Sync aus hast und es zum tearing kommt, also ein fehlerhaftes Bild. Wenn du Animationen darstellen willst, würden deine User keine echte darstellung ertasten. Frame vorbereiten, Frame Anzeigen, das ist der Weg. Wenn die Geräte nicht schneller können, verfälscht du so nur deine Animation.