Re: [Libreoffice] Handling ordering problem when properties are set one by one

On 23/01/12 21:31, Lubos Lunak wrote:
>  Hello,
>
>  I have a bug that's related to databases in Writer (menu->Edit->Exchange 
> Database and RES_HIDDENTXTFLD). The code that triggers it does a copy of the 
> document in order to do the necessary substitutions there (well, this all is 
> at least how I understand it) and during the copying it copies data 
> identifying the database used by the document. Sadly, that's at least two 
> pieces of information (data source and command, whatever exactly those two 
> are) and the code does the copying in "random" other, because it simply 
> copies a bunch of properties of the source document, and the resulting orders 
> happens to be the reverse of what it should be. The code that handles the 
> database requires the data source first and the command afterwards (which is 
> quite logical, as the latter presumably doesn't make sense without the sooner 
> first).
>
>  Technically, I get in SwXDocumentSettings::_setSingleValue() first a call 
> with HANDLE_CURRENT_DATABASE_DATA_SOURCE and then with 
> HANDLE_CURRENT_DATABASE_COMMAND. They both call first SwDoc::GetDBDesc(), 
> which first applies the command to some default data source and afterwards 
> sets the given data source without the right command afterwards. The reversed 
> ordering of the input data comes from some call far far in the past and I 
> have no idea if reusing old command does not cause a problem for other code 
> using this functionality.

i wonder, does it start doing something immediately if you set a single
property?  if nothing is actually done until later, probably we could
risk to change the setProperty so a new DATA_SOURCE doesn't clear a
previously set COMMAND; but note that i have no idea what this stuff
does anyway...

>  It seems to be quite a common way for LO code to use this 
> let's-push-all-the-data-as-properties-one-by-one approach, so I wonder what 
> the common way of avoiding this problem is? Preferably something that's not 
> an ugly hack, excuse the naivety.

i'm not aware of a general solution for this problem; i'm afraid if
there are good reasons not do a change as above, then ugly hack is in
order...  i don't remember running into such a problem before, probably
this kind of dependency is quite rare.

also, there are lots of silly implementations of XMultiPropertySet or
XTolerantMultiPropertySet or something like that in Writer that
basically loop over a sequence of PropertyVaules and call
setPropertyValue for every one; presumably it would be much faster in
some cases to convert the whole sequence to say an SfxItemSet and push
that into the core in one call...