Kompaktes Framework – Leichtes GUI-Framework?[geschlossen]

Question

Winform auf CF ist etwas schwerfällig, das Initialisieren vieler Windows-Handles nimmt viel Zeit und Speicher in Anspruch.Ein weiteres Problem ist das Fehlen einer integrierten Doppelpufferung und die mangelnde Kontrolle über die Darstellung der Benutzeroberfläche. Dies führt dazu, dass der Benutzer bei prozessorintensiven Vorgängen möglicherweise auf einen halb gerenderten Bildschirm starrt.Hübsch!

Um dieses Problem zu lösen, würde ich nach einem leichten Kontroll-Framework suchen. Gibt es bereits eines, oder müsste man es selbst basteln?

Mit leichtgewichtig meine ich eine Steuerelementbibliothek, die es einem ermöglicht, das Malen von Steuerelementen vollständig zu steuern und nicht viele teure Windows-Handles zu verwenden.

NOTIZ:Bitte suggerieren Sie nicht, dass ich den UI-Thread zu sehr betreibe.Das ist nicht der Fall.

Answer 1

Ich bin neulich darauf gestoßen, was zumindest als Ausgangspunkt hilfreich sein könnte: Fuild – Windows Mobile .NET Touch-Steuerelemente.Das Erscheinungsbild ist gut, aber es gibt keine Unterstützung für die Designzeit.Ich weiß nicht viel über den Speicherbedarf usw., aber alles ist doppelt gepuffert und die Leistung scheint ziemlich gut zu sein.

Answer 2

Ok, nur eine spontane Idee...

Wie wäre es mit der Erstellung eines Synchronisationsobjekts, z.B.kritischer Abschnitt oder einzelne Sperre in Ihrer Anwendung, die von Ihren Worker- und GUI-Threads gemeinsam genutzt wird.Überschreiben Sie die Farbe.Wenn Sie mit dem Malen beginnen, blockieren Sie alle anderen Threads, damit Sie nicht mit einem halb bemalten Bildschirm zurückbleiben, während diese die CPU belasten.

(Dies setzt natürlich voraus, dass die Präsentation eines hübschen Bildes für Ihren Benutzer das Wichtigste ist, was Sie benötigen ;) )

Answer 3

etwas langsam und Sie können das Malereignis nicht steuern, sodass der Benutzer bei prozessorintensiven Vorgängen möglicherweise auf einen halb gerenderten Bildschirm starrt.

Es ist im Allgemeinen eine schlechte Idee, teure Aufgaben im UI-Thread zu erledigen.Damit Ihre Benutzeroberfläche reaktionsfähig bleibt, sollten diese Aufgaben von einem ausgeführt werden Worker-Thread

Answer 4

Tatsächlich können Sie das Paint-Ereignis überschreiben.

Und die Idee ist, dass Sie lang laufende Vorgänge in einen separaten Thread verlagern.Das unterscheidet sich eigentlich nicht von anderen ereignisgesteuerten Frameworks. Irgendetwas das auf der Behandlung eines Paint-Ereignisses beruht, wird dafür anfällig sein.

Außerdem gibt es kein System, mit dem Sie bestimmen können, wann das Paint-Ereignis ausgelöst wird.Diese Art von Ereignis wird im Allgemeinen von der Fenstermanagerschicht ausgelöst, die sich außerhalb der Anwendung (oder sogar des Frameworks) befindet.Sie können die Veranstaltung selbst verwalten und zeitweise einfach nicht arbeiten, aber ich würde es nicht empfehlen.