Moin, On Friday 26 January 2007 12:04, Christian Stimming wrote: [...] > 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: [...] Versuche bitte, sachlich zu bleiben, ich verstehe sogar sehr gut, worauf Du hinauswillst...
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. [...] > * 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?? 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(). Im Falle von GWEN_Gui_ProgressEnd() wird dann in meinem QT-Frontend das Progress-Objekt vom Widget detached und das Widget auf WS_DESTRUCTIVE_CLOSE gesetzt (womit das Fenster von QT automatisch destroyed wird, sobald der Benutzer es schliesst). Wir koennen uns hier noch stundenlang darueber streiten, Fakt ist jedoch - wie Du an den WaitCallbacks selber festgemacht hast - das es auch bisher schon so geloest war, wie es jetzt ist. Weil es eben ein unverhaeltnismaessig grosser Aufwand waere, jeder Funktion, die irgendwann theoretisch einmal eine Funktion aufruft, die Benutzerinteraktion macht, einen Pointer auf die gewuenschte GUI mitzugeben. Der Nutzen daraus ist zudem auch noch fragwuerdig. Du kannst natuerlich Faelle konstruieren, in denen es zu Problemen kommen kann. Tatsache ist aber auch, dass die einzigen Aufrufer der GWEN_GUI-Funktionen AqBanking/Gwenhywfar/Libchipcard selbst sind, und die arbeiten bisher nun mal nicht so, dass Deine umfangreiche Aenderung noetig waere. Ich habe jedenfall wenig Musse, nur aus akademischen Gruenden solch grosse Aenderungen zu machen, wenn mir daraus nicht ein mindestens ebenbuertiger Nutzen erwaechst. Die bisher schon umgestellten Anwendungen und Plugins zeigen, dass es auch bisher schon gut funktioniert, und nicht einmal Du selbst mit Gnucash benoetigst diese Aenderungen. [...] > 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 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. Gruss Martin -- "Things are only impossible until they're not" AqBanking - http://www.aqbanking.de/ LibChipcard - http://www.libchipcard.de/ ------------------------------------------------------------------------- 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
