Open a new XML Form Document. Go to instanceData. Add an element. Have a look at bindings, if a binding has been created. (If not: create a binding or save and restart the document or download this attachment instead: https://bugs.documentfoundation.org/attachment.cgi?id=186599). Create a form control. Set binding for the form control. You could get something like this: https://bugs.documentfoundation.org/attachment.cgi?id=187027 There are many labels which are greyed out. This labels should be greyed out, because it should be impossible to change a default datatype, which is included for XML form documents. But: You could change the content for this greyed out labels and will change it for all datatype, in screenshot for fields with data types "day". Fields should only be activated for creating new data types, not for changing existing old data types. Type the button right from the chosen data type. Might be it looks a little better, something like +… . Now you could create a new data type and the greyed out labels will show: activated. And also the input fields for this labels should only be activated for a new created datatype of your form. Bug appears with all installed versions here.
I gave a try to this one, thought it would be not too hard but the whole mechanism doesn't use usual ui Glade file, welding process, etc. If someone is interested, here's some code pointer: #0 pcr::(anonymous namespace)::EnablePropertyUIElement::updateUIForKey(rtl::OUString const&, bool) const (this=0x7f757589fbc0, _rKey="Type", _bFlag=true) at extensions/source/propctrlr/composeduiupdate.cxx:512 but since I failed to see where we may disable the entry associated to the label, perhaps it's not the right one. Caolán: just for curiosity, do you continue the welding process or this kind of remnant would be far too long to convert? I mean with a usual mechanism, I'm quite sure it would have been easy to fix. BTW, locally I used g++ -E to convert extensions/source/propctrlr/formmetadata since I was stuck just searching about RID_STR_XSD_WHITESPACES git grep -n RID_STR_XSD_WHITESPACES extensions/inc/strings.hrc:212:#define RID_STR_XSD_WHITESPACES NC_("RID_STR_XSD_WHITESPACES", "Whitespaces") after conversion, there's this extra line: extensions/source/propctrlr/formmetadata.cxx:159: OPropertyInfoImpl( PROPERTY_XSD_WHITESPACES, PROPERTY_ID_XSD_WHITESPACES, PcrRes( RID_STR_XSD_WHITESPACES ), 55, HID_PROP_XSD_WHITESPACES, PROP_FLAG_FORM_VISIBLE | PROP_FLAG_DATA_PROPERTY | PROP_FLAG_ENUM ) that's why I hate the preprocessor macro programming, preprocessor should be just to deal with include file or system specificities (little/big endian)
It is welded in the sense that eventually it does get built out of snippets of .uis and uses native gtk widgets under gtk. But, yeah, this part of "extensions" and forms (and dbaccess) form a family of code which knows the uno api very well, and knows obscurities of certain vcl features. More like clockwork than brickwork :-) so it can be frustrating.
(In reply to Caolán McNamara from comment #2) > It is welded in the sense that eventually it does get built out of snippets > of .uis and uses native gtk widgets under gtk. But, yeah, this part of > "extensions" and forms (and dbaccess) form a family of code which knows the > uno api very well, and knows obscurities of certain vcl features. More like > clockwork than brickwork :-) so it can be frustrating. Thank you for the feedback but after several hours on several days trying to untangle all calls of type pcr::OPropertyBrowserController::enablePropertyUIElements and pcr::OBrowserLine::EnablePropertyLine, it seems UNO is definitely not for me => uncc myself