Hi, On Freitag 27 August 2010, Christian Stimming wrote: [...] > don't want to add any workload at the start-up time. So the aqbanking > init should be done at the first usage of the gncmod-aqbanking module, > just as it is done right now, but this is only a minor issue and not > really a technical problem.) [...]
Even better. [...] > In the meantime, I proposed for aqbanking to handle the case with the > wrong GWEN_GUI object more gracefully, i.e. instead of an assert() on > the correct derived type, there could also be an error message and [...] Those asserts are in for a purpose: They flag quite a serious error which MUST not happen in an application. If it does, it needs to be fixed, and to detect this problem and have a stacktrace to find the exact path which led to it is crucial. However, the changes I proposes wouldn't be that big: If I remember correctly you have different functions for creating a banking object and a GWEN_GUI object. I would recommend that whichever function is called first should init both the GUI and AqBanking object. All further calls should then return those one-time created objects. On plugin-deinit time those objects could then be destroyed (and all other code creating, initializing, deinitializing, destroying GUI or banking objects should then be disabled. This would work as well with AqBanking4, so it wouldn't be a Aqbanking5`ism. Regards Martin -- "Things are only impossible until they're not" Martin Preuss - http://www2.aquamaniac.de/ AqBanking - http://www.aqbanking.de/ LibChipcard - http://www.libchipcard.de/ _______________________________________________ gnucash-devel mailing list [email protected] https://lists.gnucash.org/mailman/listinfo/gnucash-devel
