Kommunikation zwischen Programmlogik und GUI



  • Hallo Allerseits,

    ich überlege mir grad wie ich meine Programlogik mit der GUI kommunizieren lassen!? In der Programlogic übertrage ich daten, und will bswp. den aktuellen Übertragungsstatus anzeigen.

    (A) Ich über gebe der Programlogik komponenten den Fensterhandle der GUI Fensters, und schike per Nachrichten/Events den aktuellen zustanden an das Fenster.

    (B) Ich implementiere in der Programlogikkomponenten eine Funktion GetStatus, und rufe die in einem Timer auf der gui auf.

    Was gäbe es noch für Varianten. Welche ist die beste?

    Schönen Abend noch



  • Du könntest einen Funktionszeiger/delegate von der GUI an die Logik übergeben, über die der Algorithmus aufruft und den Arbeitsstand in % übergibt. Diese Technik sollte alles entkoppeln, die Programmlogik muss nichts von der GUI wissen.



  • (C) ähnlich wie (B), bloss die "programmlogik" hat nen event "data changed" der immer dann feuert wenn sich was geändert hat was man anzeigen könnte - dadurch musst du nimmer pollen



  • Ja das mit dem event wäre doch dann (A) oder ? wenn ich via PostMessage ein status event an die GUI bzw. Fenster Handle schicke??



  • Schau dir vielleicht mal Adobes Adam&Eve an, dass sind zwei Opensource Libraries, die das Problem adressieren.





  • Fass ich mal zusammen:

    (A) Fenster-Handle und via Send/PostMessage "DataChange" Event vom Object an GUI schicken

    (B) Fenster GUI pollt auf änderung des Objekts

    (C) FunktionsPointer, Callback Funktion der GUI an Objekt übergeben.

    (D) OBServer Pattern, Objekt besitzt Zeiger auf GUI und ruft bei Änderung eine virtualle funktion auf (ähnlich wie Callback prinzip)

    Also was ist nur die beste Option?



  • Ich mochte (D) recht gerne.

    (A) ist sehr abhängig von der GUI-Lib, d.h. die Programmlogik muß doch etwas über die API wissen, oder Du mußt noch mal zusätzlich eine Abstraktion einführen

    (B) ist ziemlich brachial... ist der Timer schnell, blockiert er viel Rechenzeit, ist er langsam, sieht der Benutzer u.U., daß sich Daten nicht sofort ändern sondern erst im nächsten Zyklus

    (C) ein FPtr kann nur auf eine Funktion zeigen... aber oft muß man ja viele Dinge benachrichtigen. Das ObserverPat hat den Vorteil, daß man auch andere Leute benachrichtigen kann, also z.B. auch Objekte innerhalb der Programmlogik, oder daß man Variablen (in Objekte verpackt) mitschicken kann. Ist mit FPtrs auch möglich, aber sehr C-Style



  • (B) ist ziemlich brachial... ist der Timer schnell, blockiert er viel Rechenzeit, ist er langsam, sieht der Benutzer u.U., daß sich Daten nicht sofort ändern sondern erst im nächsten Zyklus

    wenn die gui gezeichnet wird, wird sie ja eh einen status abfragen, ob der als member abgespeichert ist und synchronisiert weden muss oder direkt am objekt ist, ist socke wie hose 😕



  • Bei Variante (D) hab ich ja ein OBserver Interface oder, welches ich in der GUI Klasse, Fenster etc. ableiten muss, un die "virtuelle" Funktion Implementieren muss?? Soweit ich es verstanden habe.

    Variante (C) muss ich den FctPtr einer Memberfunktion der Fensterklasse übergeben, welche vom Objekt aufgerufen wird bei Änderung... muss diese funktion dann nich statisch sein???



  • Marc++us schrieb:

    (C) ein FPtr kann nur auf eine Funktion zeigen... aber oft muß man ja viele Dinge benachrichtigen. Das ObserverPat hat den Vorteil, daß man auch andere Leute benachrichtigen kann, also z.B. auch Objekte innerhalb der Programmlogik, oder daß man Variablen (in Objekte verpackt) mitschicken kann. Ist mit FPtrs auch möglich, aber sehr C-Style

    Wenn man alles aus C++ Sicht sieht kann man natürlich auf die Idee kommen ein Event müsste ein fptr/mfptr sein.
    Ein Event kann aber auch sowas wie in C# sein, da kann man auch viele "Dinge benachrichtigen" (EDIT: lol - vergessen Satz fertigzuschreiben).
    Der Unterschied zu (D) Observer Pattern ist IMO nicht gross.

    Wichtig ist denke ich einfach dass man keine allzu enge Koppelung hat.



  • Wie lass ich den ein fctptr auf ne member funktion zeigen?



  • schlampkopf schrieb:

    Wie lass ich den ein fctptr auf ne member funktion zeigen?

    functor 😉



  • Ok liebe leute,

    dann würde ihr mir definitv Variante (C) und (D) empfehlen. Variante (B) vergessen, bisherhab ich es mit Variante (A) gemacht.



  • Es ist ja an sich beides das bleiche. In der Zeiger-Variante gibt es nur kein Interface von dem abgeleitet werden muss (siehe zB. boost- oder qt-signale).

    Mir gefällt die Lösung in Java besser, wo man anhand des Interfaces bereits in der benachrichtigten Klasse sieht, welche Events sie bekommt. Bei Signalen (also beliebigen Funktionen) sieht man eine eventuelle Verbindung zu anderen Klassen erst im Code. Man könnte natürlich auch Kommentare drüber schreiben aber wer macht das schon...


Anmelden zum Antworten