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

Hi Stephan,

Anyway, you must be right with that it's not a good idea to change the staticType_, so I added an 
other fix which does not affect staticType_, but uses a typeHint only for parsing a specific value 
from XCU file.
Can you review this change please? I hope you're happy with that:
https://gerrit.libreoffice.org/#/c/34933/

Thanks,
Tamás

On Monday, March 06, 2017 18:40 GMT, "Tamas Zolnai" <tamas.zolnai@collabora.co.uk> wrote:

> 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