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.zol...@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 _______________________________________________ LibreOffice mailing list LibreOffice@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/libreoffice
