https://issues.apache.org/ooo/show_bug.cgi?id=123144
Ariel Constenla-Haile <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |[email protected] --- Comment #15 from Ariel Constenla-Haile <[email protected]> --- (In reply to Ariel Constenla-Haile from comment #13) > The data source settings are stored in both document's settings.xml: > > <config:config-item config:name="CurrentDatabaseCommand" > config:type="string">biblio</config:config-item> > <config:config-item config:name="CurrentDatabaseCommandType" > config:type="int">0</config:config-item> > <config:config-item config:name="CurrentDatabaseDataSource" > config:type="string">Bibliography</config:config-item> This happens if you save the document with "Save as" without modifying it. But the settings are in different order: A) in 3.4.1: <config:config-item config:name="CurrentDatabaseDataSource" config:type="string">Bibliography</config:config-item> <config:config-item config:name="CurrentDatabaseCommand" config:type="string">biblio</config:config-item> <config:config-item config:name="CurrentDatabaseCommandType" config:type="int">0</config:config-item> CurrentDatabaseDataSource CurrentDatabaseCommand CurrentDatabaseCommandType This is the order in SwDocumentSettingsPropertyHandles (sw/source/ui/uno/SwXDocumentSettings.cxx) B) in 4.0.0: <config:config-item config:name="CurrentDatabaseCommand" config:type="string">biblio</config:config-item> <config:config-item config:name="CurrentDatabaseDataSource" config:type="string">Bibliography</config:config-item> <config:config-item config:name="CurrentDatabaseCommandType" config:type="int">0</config:config-item> CurrentDatabaseCommand CurrentDatabaseDataSource CurrentDatabaseCommandType C) If the document is stored after being modified in 4.0.0: <config:config-item config:name="CurrentDatabaseCommand" config:type="string"/> <config:config-item config:name="CurrentDatabaseDataSource" config:type="string">Bibliography</config:config-item> <config:config-item config:name="CurrentDatabaseCommandType" config:type="int">0</config:config-item> CurrentDatabaseCommand <<==== empty string! CurrentDatabaseDataSource CurrentDatabaseCommandType The main bug is that settings the current database settings read from the document settings stored in settings.xml depends on the order the properties are set for it to work, where CurrentDatabaseDataSource must be the first one to be set: Document settings are set in void SwXDocumentSettings::_setSingleValue( const comphelper::PropertyInfo & rInfo, const uno::Any &rValue ) (sw/source/ui/uno/SwXDocumentSettings.cxx) case HANDLE_CURRENT_DATABASE_DATA_SOURCE: { SwDBData aData = mpDoc->GetDBData(); if ( rValue >>= aData.sDataSource ) mpDoc->ChgDBData( aData ); } break; case HANDLE_CURRENT_DATABASE_COMMAND: { SwDBData aData = mpDoc->GetDBData(); if ( rValue >>= aData.sCommand ) mpDoc->ChgDBData( aData ); } break; case HANDLE_CURRENT_DATABASE_COMMAND_TYPE: { SwDBData aData = mpDoc->GetDBData(); if ( rValue >>= aData.nCommandType ) mpDoc->ChgDBData( aData ); } break; SwDBData SwDoc::GetDBData() calls const SwDBData& SwDoc::GetDBDesc() (sw/source/core/doc/docfld.cxx) The algorithm there is: if the datasource name has zero length, then try to get it from a db field in use in the document When the document is just loaded, it has no db fields in use yet, so the DS name is not set. If the DS name was not set above, then get the DB data from the address DB (GetNewDBMgr()->GetAddressDBName() might return a default constructed SwDBData if there is no addressbook set in the configuration) If the document settings are set in the following order: 1. CurrentDatabaseCommand = biblio 2. CurrentDatabaseDataSource = Bibliography 3. CurrentDatabaseCommandType = 0 1) setting the DB command first works: - mpDoc->GetDBData() returns a default constructed SwDBData( sDataSource = ""; sCommand = ""; nCommandType = 0) if there is no default address book. - "biblio" is set in aData.sCommand and SwDoc::ChgDBData updates its aDBData 2) the bug occurs when setting the datasource is not the first SwDBData member to be set: - mpDoc->GetDBData() checks only aDBData.sDataSource.getLength(), it does not take into account if one of the other members have been set. It will try to get the DS name from the DB fields, but at this point there are no fields in use. It will then return GetNewDBMgr()->GetAddressDBName() which might be a default constructed SwData or the address book which might be different from the DB settings store in the document settings. In both cases, the CurrentDatabaseCommand set previously, is now lost. Supposing that there is no address book set - step 1 sets aDBData with ( sDataSource = ""; sCommand = "biblio"; nCommandType = 0) - step 2 with ( sDataSource = "Bibliography"; sCommand = ""; nCommandType = 0) - step 3 with ( sDataSource = "Bibliography"; sCommand = ""; nCommandType = 0) Thus, sCommand is empty. This is the result in (C) above, where the respective setting has no value: <config:config-item config:name="CurrentDatabaseCommand" config:type="string"/> ------------------------ Conclusion, CurrentDatabaseDataSource must be the first DB property to be set. This could be guaranteed if comphelper::MasterPropertySetInfo stored the properties in the an orderer map, SwXDocumentSettings creates its property info in the right order, and properties are set on loading and get on saving in the right order. But all of this is error prone; the ground error is in const SwDBData& SwDoc::GetDBDesc() that only checks if SwDBData's sDataSource member is empty or not, despite that the other members might have been set before. A possible solution would be to initialize nCommandType in -1, and add a operator! that checks if any of the members are set; then in const SwDBData& SwDoc::GetDBDesc() check if (!aDBData) instead of if(!aDBData.sDataSource.getLength()) If this will work, or introduce new regressions, I've no idea; so setting orw in CC who might be in the know. -- You are receiving this mail because: You are on the CC list for the bug. You are the assignee for the bug. You are watching all bug changes.
