On Sunday 15 August 2004 4:38, Derek Atkins wrote: > Neil Williams <[EMAIL PROTECTED]> writes: > > Should version and version_check be compared/set in a merge? > > _maybe_. IIRC these are used for object versioining between the > engine and the backend. So, I'm not sure exactly what a "merge" would > do to them.
OK, I'll leave those alone. I can't see a situation where you'd need to overwrite the version of objects in the target book with objects from an import book - unless people want to go back in time. It probably shouldn't be default behaviour even if it was useful occasionally. > > Various objects use these members in the structs, they can be merged > > using QOF_TYPE_INT32 with no bother - question is, should they? > > I've never heard of QOF_TYPE_INT32. I don't think we have one, nor do > I think we should have one. I can't imagine any user-servicible parts > that are only 32-bits wide. We've got QOF_TYPE_NUMERIC for numeric > values and QOF_TYPE_INT64 for non-"numeric" numbers. Isn't QOF_TYPE_INT32 useful for gint? Particularly for these enum values where the maximum is about 12 or for gncBillTermGetDueDays. The merge isn't just working on user-serviceable parts, I need to be able to set and get every part of each object, subject to those parameters that are calculated fields, otherwise some objects will be left with corrupt / incomplete parameter data. business/business-core/gncBillTerm.h:Uses a standard gint (QOF_TYPE_INT32) to set the enumerator > > I've got a complete list of current problems: > > In the table, when the specified object is merged, data in the specified > > struct member variables will not be read, compared or set. Existing > > values in the target QofBook will not be changed. Where the object is QOF > > compatible, if the object is new (MERGE_NEW) the listed variable will be > > set to the default value given in the table. > > http://www.codehelp.co.uk/code/problems.html#AEN378 > > Ok, so you're still not performing any compares.. Got it. Umm, yes, I am - the section quoted relates to the objects I can't yet merge - a lot of which won't be usable until gnc_commodity is fixed. I'm already comparing and merging any object that resolves to the basic QOF_TYPE fundamentals. It's fine for simple QOF objects and it's ready to move on to complex objects that contain more than just simple strings, dates, integers, booleans and gnc_numerics. Which is why I'm adding a lot of QofSetterFunc and a few QofAccessFunc declarations to engine and business objects - I can't test the code until the objects are ready. Plus adding the essential create: declarations for QofObject - a merge isn't much use if it can only change existing objects, it needs to create new ones too. That's already working. > > I'm working on the business objects too, making them QOF compatible and > > I'll post another table of the business objects discrepancies on the same > > page. > > "making them qof compatible"??? They should've been nearly completely > QOF compatible.. Some were missing QofObject definitions (so they would never appear in the merge) and most had incomplete parameter lists. I've added a few parameters to many objects so that each object is fully described to QOF - excluding those parameters like balances that are exclusively calculated and should not be set. I've added more QofSetterFunc definitions where there were none, I was going to add a few wrappers to convert enums to gint but : > > One solution I've used locally is to use QOF-compatible wrappers. e.g. > > for functions that set or get enums, I'm using a gint wrapper: > > void gncBillTermSetType_q (GncBillTerm *term, gint type) > > { > > GncBillTermType q = type; > > if(!q) return; > > gncBillTermSetType(term, q); > > } > > > > Is this satisfactory? (Is it unnecessary?) > > Yes, it is not necessary. You can pass an int into an enum. What about the return value? If I use a get_fcn that returns a GncBillTermType can I rely on implicit casting to a gint or are there situations where it's safer to use an explicit cast, as here: gint gncBillTermGetType_q (GncBillTerm *term) { if(!term) return 0; return (gint)gncBillTermGetType(term); } -- Neil Williams ============= http://www.codehelp.co.uk/ http://www.dclug.org.uk/ http://www.isbn.org.uk/ http://sourceforge.net/projects/isbnsearch/ http://www.biglumber.com/x/web?qs=0x8801094A28BCB3E3
pgpNWSMys217k.pgp
Description: signature
_______________________________________________ gnucash-devel mailing list [EMAIL PROTECTED] https://lists.gnucash.org/mailman/listinfo/gnucash-devel
