Re: Revert "tdf#106283: Registry settings are not read properly on Windows"

[Tamas Zolnai]

Hi Stephan,

I saw you reverted my change about config manager. Can you help me understanding your comments, please. It's not all clear.

Your commit message was:
"Revert "tdf#106283: Registry settings are not read properly on Windows"
This reverts commit 8cfda7206139b3017346c435591c77c9741ba8ee.  The problem in
that issue is that the configmgr/source/winreg.cxx code generates .xcu data
where such an extension prop doesn't have an oor:type attribute, which is not
allowed.[...]" 

So it's clear that the generated xcu file from Windows registry is incomplete\invalid, so it can be a good idea to fix it, but this would take an amount of time since registry keys used for LO are always strings as I see (see comments in configmgr/source/winreg.cxx) and I guess it will work on the same way for the end of the time for compatibility reasons. So it is impossible to find out the type from the registry key. To find out  that we need to parse the corresponding xcd file here too (as configmgr code does).
It can be a solution, but as I see you created a bug report (tdf#92755) about avoiding using these temporary xcu files for Windows registry, so I'm not sure it worth to try to make these xcu files valid (having type information), if they will be removed later, right? So I'm not sure why you suggest to fix the code which generates these xcu files. (your comment on bugzilla: "[...] For such extension props it must generate an oor:type attribute.[...]") Also fixing this bug by replacing xcu generation with a better implementation which using configmgr's internal data would also take me very far from fixing the bug I intended to (tdf#106283).

"[...]On the other hand, it is important that the PropertyNode representing
such an extension prop has a staticType_ of TYPE_ANY, so that later layers or
programmatic calls can store values of different type."

So this part is also not clear to me. What do you mean later? When can it happen that the same property get a different type, which is defined in the specific xcu/xcd file?
What do you mean programmatic calls can store values of different type? When a programmatic call would store a different typed value for a typed property? One specific property always defined with a type even if this property is part of an extensible group, right? So I can't see why this type would be overriden by a programmatic call? Or if this is a use case (using properties as something in which you can store anything) then I guess this also must be true for all properties, not only a member of an extensible group. What's the difference?

I also tested that case when an extensible group has properties with different types (xs:boolean-xs:long) and it also works. I thought you might thinking of that case and later means later when the specific extensible group is extended with a new property with a different type. In this case my change works. So I would appreciate if you can point out a use case when this code change is problematic.

Thanks,
Tamás