-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Martin Preuss schrieb: >> Den pointer zum parent-window hast du doch selber in QGui exakt so >> implementiert (qgui.h:23) > > Ich habe beschrieben, warum der Aufwand dies so zu implementieren, wie Du das > gerne haben moechtest, einfach unverhaeltnismaessig ist. Wie gesagt muessten > alle Funktionen, die irgendwann mal Funktionen aufrufen, die eine Interaktion > benoetigen, diesen Pointer mitfuehren.
Nein, müssten sie nicht. Das mussten sie in aqbanking2/gwen2 auch nicht. Du änderst in gwen3 das Verhalten gegenüber gwen2, und darum geht es die ganze Zeit. >> * 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 GWEN_Objekt wird nie geloescht, bestenfalls am Ende des Programmes?? Natürlich wird es gelöscht: Mit parent-window W1 wurde das GWEN_GUI Objekt gui1 erzeugt und mit GWEN_Gui_SetGui(gui1) gesetzt; wenn dann mit parent-window W2 das GWEN_GUI Objekt gui2 erzeugt und mit GWEN_Gui_SetGui(gui2) gesetzt wird, wird in gui.c:81 das Objekt gui1 gelöscht. > Ich kann problemlos mehrere Fenster offenstehen lassen. Wenn der Benutzer es > sich naemlich anders ueberlegt, wird bei Progress-Fenstern immer > GWEN_Gui_ProgressEnd() aufgerufen bzw bei Verwendung von GWEN_Gui_ShowBox() > immer auch GWEN_Gui_HideBox(). Das hab ich auch nie bezweifelt. Aber du beschreibst ja genau den umgekehrten Fall von meiner Kritik: Du redest davon, dass *aqbanking* mehrere Fenster aufmachen will. Die gehören dann natürlich alle zum gemeinsamen *einen* parent-window, und das ist mit statischer Variable natürlich angemessen benutzbar. Ich rede aber vom anderen Fall: ein zweites parent-Window will ein zweites GWEN_GUI-Objekt erzeugen und benutzen. > Ich habe jedenfall wenig Musse, nur aus akademischen Gruenden > Versuche bitte, sachlich zu bleiben > [...] >> 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. > [...] > > Richtig, aber was nuetzt Dir denn das? Dieser Pointer wird beim Initialiseren > von AqBanking gesetzt und anschliessend nicht mehr geaendert. Du meinst, das war auch nur eine statische Variable? Hmmmm... wenn ich das bemerkt hätte, hätte ich mich auch damals schon mit dem identischen Einwand gemeldet. Oder ich hab das falsch verstanden? > Du kannst also > damit immer noch nicht mehrere Aktionen in parallelen Fenstern ausfuehren, > weil beispielsweise das CryptToken immer nur den einen Pointer kennt, und > damit gar nicht unterscheiden koennte, in welchem Context es nun aufgerufen > wird - sprich welches Widget nun in der GUI der tatsaechliche Parent waere. Ich rede davon, dass es zwei AB_BANKING-Objekte gibt, banking1 und banking2. Damit (so dachte ich bisher in aqbanking2) würde das CryptToken, welches von banking1 aus aktiviert wird, auch über einen CryptManager c1 die callbacks von banking1 aufrufen, die dann als parent-window W1 verwenden. Wogegen ein anderes CryptToken, welches von banking2 aus aktiviert wird, über einen CryptManager c2 die callbacks von banking2 benutzt, die dann als parent-window W2 verwenden. Eine thread-safety/multithreading also zumindest auf Ebene der GUI-Aufrufe. Auch wenn mir völlig klar ist und ich auch akzeptiere, dass eine *generelle* thread-safety an diversen Stellen größere Umbauten erfordern würde und die deshalb (vorerst) nicht angestrebt wird, aber davon rede ich ja auch nicht. Ich verstehe auch nicht, warum du meinst, dass ein nicht-statisches GWEN_GUI denn so viel Aufwand wäre. Es wäre lediglich notwendig, dass auf *irgendeinem* Weg die unteren Plugins (wo die progress/msgbox-Aufrufe herkommen) eben an einen Pointer auf das GWEN_GUI-Objekt herankommen müssen. Dazu müssen die Konstruktoren eben einen Pointer mehr übernehmen, falls sie nicht über das jeweilige parent-Objekt (Provider oder sonstwas) anderweitig an die zugehörige GWEN_GUI herankommen. Soweit ich das überblicke, hat das im Prinzip bei gwen2 via dem CryptManager auch ohne gigantischen Aufwand geklappt. Gruß Christian -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.1 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQCVAwUBRbn/HWXAi+BfhivFAQJddwP+PyTa2oRfm4E36Rn5rCi/5OV+wUcygfXt SVTUBj+1xKzBpj70T4BlUR5KgDHUB6WJ6nR2LYXRno0eglZAzUzOa4wronIQWddy fjkNO14iYfqwN98xOORgW8QZy7dNlW72sZeHuT+Kn1uhizOjH/G9p1PXdYpJCIlx xJu4QziO278= =GQb8 -----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
