aqbanking5 and ofxdc can crash gnucash trunk

[Christian Stimming]

Zitat von David Reiser <dbreiser at earthlink.net>:
> * 12:15:31  WARN <gwenhywfar> inherit.c:  180: Type "5f47140b" not  
> derived from this base type
> Assertion failed: (xgui), function AB_Gui_ReadDialogPrefs, file  
> abgui.c, line 246.
> ...
>
> Martin thinks that it's related to gnucash still using multiple  
> GWEN_GUI objects:
> "Only one of those objects is derived from AB_GUI, and for reasons  
> unknown to me at some times a false GUI object is chosen by Gnucash  
> ...   I recommended multiple times to really, really create the GUI  
> object and init AqBanking once only (!), preferably upon plugin init."

I completely agree with Martin. However, someone on the gnucash side  
needs to sit down and actually do this, i.e. modifying the full  
import-export/aqbanking module to remove the second GWEN_GUI object  
*and* making sure everything continues to work as before. So far  
nobody has done this work, so we need to get along with what's  
currently in there.

(Oh, and FTR I do not agree with the proposal to do this at plugin  
init, because the gnucash start-up time is already way too long and I  
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.)

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  
simply returning from that function. That concerns all assert(xgui)  
statements in abgui.c, and this would be in line with some other  
argument checking in those functions - if some of the arguments are  
NULL, the functions simply do nothing. Even though we still need to  
change the implementation on the gnucash side, with that change on the  
aqbanking side we would at least avoid a crash with the current state  
of the code.

Best Regards,

Christian