-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Martin Preuss schrieb:
>> Ich halte das für ein GUI-Programm schon aus Prinzip für den falschen
>> Ansatz. Die App hat nun mal viele verschiedene Fenster. Bei
>> Benutzer-Rückfragen kann irgendeines der existierenden Fenster das
>> jeweilige parent-window sein, inklusive jeweiliger Zuständigkeit fürs
>> Löschen. Ich erwarte von einem callback-Objekt wie GWEN_GUI, dass ich im
>> callback-Objekt abspeichern kann, zu welchem konkreten parent-window
>> dieses callback-Objekt denn nun gehört. 
> [...]
> 
> Na und? Das ist Dir doch weiterhin unbenommen? Du kannst doch immer noch 
> mehrere Fenster gleichzeitig offenhaben? Und welches Fenster das jeweilige 
> Parent-Window eines eventuell angezeigten Widgets ist, hat doch nichts mit 
> den GWEN_GUI-Funktionen zu tun?

Doch, natürlich hat es das. Denn im GWEN_GUI-Objekt oder Ableitungen
steckt doch der pointer zum parent-Window mit drin. Und davon muss es
parallel mehrere geben können, denn die App kann nun mal von
unterschiedlichen parent-Windows aus irgendwas aus aqbanking/GWEN_GUI
aufrufen.

Den pointer zum parent-window hast du doch selber in QGui exakt so
implementiert (qgui.h:23), und genauso würde ich das auch erwarten und
selber so machen. Und das bedeutet, dass das statische GWEN_GUI hier
verbietet, dass mehrere parent-Windows existieren können.

Ich hab das Gefühl, du verstehst meinen Kritikpunkt überhaupt nicht. Ich
hab doch schon vorher ein konkretes Beispiel geschrieben:

* Das App-window W1 beginnt eine aqbanking-Aktion und erzeugt deshalb
ein GWEN_GUI mit parent-window W1.

* Aus irgendeinem Grund lässt der User dort aber irgendwas unfertig
liegen (z.B. die GetPin-MsgBox) und ruft aus App-window W2 eine andere
aqbanking-Aktion. Deshalb will die App nun ein GWEN_GUI mit
parent-window W2 erzeugen. Wie du's in QGui auch so gemacht hast, muss
also ein neues GWEN_GUI/QGui-Objekt mit dem abweichenden parent-widget
erzeugt werden.

* Da es aber nur ein einziges statisches GWEN_GUI gibt, geht das nicht.
Stattdessen wird das GWEN_GUI-Objekt zum parent-window W1 gelöscht
(gui.c:81) und es gibt nur noch jenes zum parent-window W2.

> [...]
>> Das muss doch nicht eine Verbindung von AB_BANKING und GWEN_GUI
>> bedeuten. Ich geh nur auf die Barrikaden wegen der statischen Variable
>> anstelle eines jeweils übergebenen pointers. Also in einem
>> GWEN_CryptToken dann eben anstelle GWEN_GUI_msgBox("foo", "bar");
>> stattdessen GWEN_GUI_msgBox(gui_object, "foo", "bar"); und das
>> gui_object muss dann eben vorher bei dem Aufruf des GWEN_CryptToken mit
>> übergeben worden sein. Ein kleines bisschen mehr Schreibarbeit, aber nun
>> wirklich kein technisches Hindernis.
> [...]
> 
> Von wegen "ein kleines bischen"...
> Das CryptToken - wie jedes andere Plugin - interessiert sich ueberhaupt nicht 
> fuer den Pointer. Dennoch muesste es diesen Pointer vor allem bei jedem 
> Funktionsaufruf mitfuehren (als Argument). 

Das war in gwenhywfar2 aber immer so gelöst. Zumindest für die MsgBox
(GetPin etc.) Rückfragen: Das CryptToken hatte einen Pointer zum
CryptManager/PluginManager selber gespeichert, der wiederum zu
AB_BANKING (oder noch irgendwelchen Zwischenstufen) und damit dem
callback-Objekt.

> Und das gilt nicht nur fuer das 
> CryptToken: Auch alle Gwen-Module, die ProgressStart() verwenden, muessten in 
> den Funktionen einen Pointer auf das GUI-Objekt haben. 

Hm... du meinst jene Funktionen, die bisher über WaitCallback liefen?
Oha, die waren ja schon bisher über eine statische Variable (bzw.
- -liste) in waitcallback.c implementiert. Dann war das Zufall, dass mir
das nie aufgefallen ist -- das finde ich dann in gwenhywfar2 auch schon
prinzipiell problematisch. Die meine ich hier aber nicht.

Ich beziehe mich hier auf die MsgBox-Funktionen, und die waren in
gwenhywfar2 eben *nicht* über eine statische Variable geregelt, sondern
über jeweils einen Pointer zum callback-Objekt über diverse Zwischenstufen.

Gruß

Christian
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.1 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iQCVAwUBRbngTGXAi+BfhivFAQK/OQP+P8tbynAwEC37iXnpTTZ4m7q5TRouUiui
VMncus9VqKiSCDUzwVCzKmRJzt+LJ7rX4V54VK8g0ovdyiAgokUgzjsAbWOJe0X2
KrNarGb7R5+Y5Di4UM1LPRP7LLvYlyDiXer6lu4mL5MyH3JIMJCvcExSjh8mZw4A
wv+KESkYXIw=
=dB4W
-----END PGP SIGNATURE-----

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Aqbanking-devel mailing list
Aqbanking-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/aqbanking-devel

Reply via email to