-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Martin Preuss schrieb: > [...] >> Kannst du eine Anleitung geben, wie eine bisher auf AB_Banking >> basierende callback-GUI nun ins gwen3-framework umgesetzt wird? > [...] > > Du musst im einfachsten Fall lediglich ein Objekt mittels GWEN_Gui_new() > erstellen, dann die einzelnen Callbacks setzen (z.B. > GWEN_Gui_SetMessageBoxFn), und anschliessend GWEN_Gui_SetGui() aufrufen, um > diese GUI-Implementierung zur aktiven zu machen.
Im Prinzip okay. Nur eine Unklarheit: Wie kommt denn die Verknüpfung vom AB_BANKING-Objekt zum neu gesetzten GWEN_GUI-Objekt zustande? Sprich, woher weiß das AB_BANKING Objekt, von welchem GWEN_GUI-Objekt es nun die callbacks aufruft? .... oooooh. Ich entdecke gerade, dass du in gui.c das GWEN_GUI als static variable (also prozessweit) ablegen willst, und deshalb in gui.h die tatsächlichen Aufrufe wie GWEN_Gui_MessageBox dann ohne eigenes GWEN_GUI Objekt aufgerufen werden. Uuuups. Das finde ich, sorry, gar nicht gut. Ich bitte imständig darum, dass du gerade bei dieser Interaktivitäts-Sache die Interaction-Funktionen *immer* mit zugehörigem Objekt aufrufst. Dass also ein AB_BANKING-Objekt auch (woher auch immer) einen Pointer auf sein eigenes GWEN_GUI-Objekt hat und dieses bei jedem Aufruf einer Interaction-Funktion auch übergibt. Wenn du das an dieser Stelle über die statische Variable laufen lassen lässt, geht das gesamte Objektorientierte framework den Bach runter, denn durch diese eine statische Variable werden nun alle (backends wie apps) dazu gezwungen, so zu programmieren, dass man auf diese statische Variable eingestellt ist. Spontanes Beispielszenario aus gnucash: User macht ein Online-Action-Fenster auf (welches ggf. ein log-widget enthält), überlegt es sich anders und macht noch ein zweites auf. Bisher sind dann durch die jeweils vorhandenen Pointer auf eigene GUI-Objekte die callbacks trotzdem bei den richtigen GUI-Objekten angekommen (z.B. den log-widgets), weil eben das fälschlicherweise unbenutzte Fenster dann ein anderes Objekt war und jeder hatte seine korrekten Pointer. Mit der statischen variable dagegen würde es ein riesen-Durcheinander geben: wer ist dann für delete von welchen Objekten zuständig; was passiert, wenn das zweite Fenster dann doch abgebrochen wird und das erste wieder benutzt wird oder doch andersrum; etc. Letztlich verhalten sich User nun mal nicht-deterministisch und deshalb sollte jede Programmier-Repräsentation auch eine korrekte Trennung von potentiell parallel möglichen Operationen enthalten. Durch diese statische Variable seh ich das nicht mehr gegeben. Gruß Christian -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.1 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQCVAwUBRbiTQWXAi+BfhivFAQIFRAP/ZXt2fWTg/Nyl1/hS7qd4IdWJJ0pQc2/8 u6MWmjKvXkrOoTd5D4ZF22ZNWa0juImTmDqc33bFYBMc5ucBk4pAyE9Q0pkWUGXw rdXly3iYzXGor0dUDRj0FOByNRcRUuAJ7GxygtAGL8WM7kWiNmPxphUFFvnhto+U OD0dt1DHRNQ= =uowO -----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
