i got a warning during LO start from an extension: warn:configmgr:20172:9752:configmgr/source/xcuparser.cxx:650: unknown property "ContentFormat" in "file:///.../typedetection.xcu" according to https://api.libreoffice.org/docs/idl/ref/servicecom_1_1sun_1_1star_1_1document_1_1TypeDetection.html there should be a Property "ContentFormat"? ClipboardFormatdeprecated! [string] It was interpreted as an identifier inside clipboard. Please use new property ContentFormat instead of this now. ContentFormat [string] It's and identifier, which is used for a deep format detection. An ExtendedTypeDetection use this value to match a given content to this type. e.g. It's interpreted as the doc type of an XML stream or as an identifier inside a file header but "main.xcd" defines: <oor:component-schema oor:package="org.openoffice.TypeDetection" oor:name="Types" xml:lang="en-US"> <templates> <group oor:name="Type"> <prop oor:name="UIOrder" oor:type="xs:int" oor:nillable="false"> <value>0</value> </prop> <prop oor:name="URLPattern" oor:type="oor:string-list" oor:nillable="false"> <value/> </prop> <prop oor:name="Extensions" oor:type="oor:string-list" oor:nillable="false"> <value/> </prop> <prop oor:name="DocumentIconID" oor:type="xs:int" oor:nillable="false"> <value>0</value> </prop> <prop oor:name="MediaType" oor:type="xs:string" oor:nillable="false"> <value/> </prop> <prop oor:name="Preferred" oor:type="xs:boolean" oor:nillable="false"> <value>false</value> </prop> <prop oor:name="PreferredFilter" oor:type="xs:string" oor:nillable="false"> <value/> </prop> <prop oor:name="UIName" oor:localized="true" oor:type="xs:string"/> <prop oor:name="ClipboardFormat" oor:type="xs:string" oor:nillable="false"> <value/> </prop> <prop oor:name="DetectService" oor:type="xs:string" oor:nillable="false"> <value/> </prop> </group> </templates> <component> <set oor:name="Types" oor:node-type="Type"/> </component> </oor:component-schema>
Perhaps a merge pb with https://cgit.freedesktop.org/libreoffice/core/commit/?id=6ed41c4fe1656395d5f4ac4905570977df56f4bd ?
Just wonder if we shouldn't replace "ClipboardFormat" by "ContentFormat" in officecfg/registry/schema/org/openoffice/TypeDetection/Types.xcs or add it to preserve retro compatibility. Stephan: thought you might be interested in this one since it concerns sdk/api.
(In reply to Oliver Brinzing from comment #0) > i got a warning during LO start from an extension: > > warn:configmgr:20172:9752:configmgr/source/xcuparser.cxx:650: unknown > property "ContentFormat" in "file:///.../typedetection.xcu" What extension is that (i.e., is it publicly available)? We will need at least that typedetection.xcu to help better understand where an error could be. (`git log -SContentFormat officecfg/registry/schema/` turning up nothing makes it unlikely that there was such a configuration property in the past that was removed at some point.)
Created attachment 159368 [details] typedetection.xcu (In reply to Stephan Bergmann from comment #3) > What extension is that (i.e., is it publicly available)? We will need at > least that typedetection.xcu to help better understand where an error could > be. The extension is not public, i am adding the "typedetection.xcu" which generates the warning. If needed, i can also submit the source code via JIRA. The original idea was to introduce an own document filter for a special custom file format.
(In reply to Oliver Brinzing from comment #4) > Created attachment 159368 [details] > typedetection.xcu So that file is adding an element "KOSDOKTYPE" to the set /org.openoffice.TypeDetection.Types/Types. Such an element must be of the template type /org.openoffice.TypeDetection.Types/Type, which is a (non-extensible) group that has no property named "ContentFormat", see officecfg/registry/schema/org/openoffice/TypeDetection/Types.xcs. I think I understand your comment 0 better now. You are not wondering why LO considers that typedetection.xcu as wrong (by issuing that "warn:" line). You are wondering whether <https://git.libreoffice.org/core/+/6ed41c4fe1656395d5f4ac4905570977df56f4bd%5E!/> "INTEGRATION: CWS xmlfilter01 (1.3.6.1.32); FILE MERGED: 2003/03/14 13:32:07 as 1.3.6.1.32.1: #107711# new service ExtendedTypeDetectionFactory; new interfaces and doc for TypeDetection and FilterFactory", which made the change from deprecated ClipboardFormat to ContentFormat in the UNO properties supported by the UNOIDL service com.sun.star.document.TypeDetection, should also have adapted the configuration template type /org.openoffice.TypeDetection.Types/Type in officecfg/registry/schema/org/openoffice/TypeDetection/Types.xcs accordingly (by, say, deprecating prop ClipboardFormat and adding a prop ContentFormat). About which I have no idea. But the fact that this difference between the UNO properties documented for UNOIDL service TypeDetection and the configuration props of group Type are there for 17 years now could be a hint that things are working as intended. Oliver, what exactly (if anything) do you claim is not working if your KOSDOKTYPE element cannot provide a "ContentFormat" prop value?
(In reply to Stephan Bergmann from comment #5) > Oliver, what exactly (if anything) do you claim is not working if your > KOSDOKTYPE element cannot provide a "ContentFormat" prop value? We have no problem with the filter, it is not used at the moment because the requirements have changed in the meantime. When I started a LO Debug version I only noticed that a warning was generated and I wanted to get to the bottom of it.
Can we close this bug?...
I don't mind closing the issue as a wontfix