Created attachment 124723 [details] docx file with troublesome checkbox We received a docx file with selectors and checkboxes. Unfortunately, the checkboxes cannot be operated on. When you click on them, nothing happens. Expected result: Click on a checkbox, it should display an X, fill with color or else to show it's selected.
I see boxes on page 3 (Norma(s) de Auditoría), but these are not checkboxes, only some drawings - I can not select it in word. What is the selector?
Created attachment 126130 [details] Simplified Test Case with only Checkbox The Checkboxs on page 3 of attachment 124723 [details] in Word 2013 are disabled for editing. Here is a sample docx with Check Box Content Controls that work. We already handle Combo Box Content Controls correctly. Check Box Content Controls should be handled in a similar fashion.
Thanks for all the assistance. I will close it since it's actually how the original document was written.
Comment on attachment 124723 [details] docx file with troublesome checkbox You discovered a valid bug. Check Box Content Controls don't work, while Combo Boxes do. It's just your initial bug doc was invalid. Let's keep it open with my example.
Same in 3.5.0, but no checkbox at all in 3.3.
*** This bug has been marked as a duplicate of bug 91384 ***
It's (In reply to Luke from comment #6) > > *** This bug has been marked as a duplicate of bug 91384 *** It's not a duplicate, because the other bug is about ActiveX controls, why this bug is about content control.
** Please read this message in its entirety before responding ** To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
content controls not working in Version: 6.2.0.0.alpha0+ (x64) Build ID: dff829e863fd05bedd5bcb713cd80c10fa582932
Justin, I see that you're working on form controls now. Is this something you'd be interested in investigating?
I tried this in Word 2003, and there it also acts like a picture. So this is a fairly new feature in Word - at least the interactive part of content controls. In word 2016, I tried to save as .doc format where it warns that the controls will be turned into static content. It looks like we fall back on inserting a literal 0x2610 / 0x2612 Unicode character because of <w:t>☐</w:t> or <w:t>☒</w:t> (although that isn't strictly necessary because the code specifies the checked/unchecked possibility). <w14:checkbox> <w14:checked w14:val="0"/> <w14:checkedState w14:val="2612" w14:font="MS Gothic"/> <w14:uncheckedState w14:val="2610" w14:font="MS Gothic"/> </w14:checkbox>
Created attachment 145313 [details] CheckboxContentControl2.docx : can't use OLE checkboxes are replacement To fix this will require designing backend and UI code specifically for this situation (which appears to be for Word only). Although for most documents simply substituting our normal interactive checkbox would look fine (since it uses a 12pt sized ballot box), it lacks the flexibility of these unique checkboxes. CheckboxContentControl2.docx presents the challenging aspects of this (which looks fine in the current implementation since the checkbox is just simple text). Perhaps the best way to fix this would be to adapt the existing checkbox to handle different presentation (Unicode characters) and scaling. That would remove the need to add interactive UI code.
Created attachment 145314 [details] tdf99571_badAssumptions.patch: convert Sdt to interactive 12pt checkbox I don't plan to continue working on this, so I'll post my failed, rough proof of concept patch here. Although the original document looks great with this patch (and so probably would most documents), it fails miserably on comment 12's test.
Created attachment 145334 [details] Sample with most Content Controls available in Word 2016 Justin L, Thanks for looking into this. One thing that I don't understand is what is unique about the checkbox content control from all other content controls? As you can see from this example, all of these other content controls are not only imported, but they are also functional.
(In reply to Luke from comment #14) > As you can see from this example, all of these other content controls are > not only imported, but they are also functional. Luke, you didn't try to do anything special to the items in your example. I can break almost every one of them. 1.) Rich text control: set as "do not allow content modification". In LO, this is just plain text and not in any kind of textbox at all. The text can be modified. So really this control is not at all imported nor functional. 2.) Plain text control: set a title. In LO there is no title that appears when you click in the text. 3.) Image: set "contents cannot be edited." It can be edited in LO because it is just an image, and not even the Protect:Contents/Position/Size options have been set in LO. 4.) Choose an item.: Change the color and size of the text. In LO those settings are ignored. Plus, in Word there is no border/dropdown showing until you click on the control. That is because in Word this is just text until you click in the "area" of the control, and then it becomes something special. 6.) Empty Date picker: In Word we see "Click or tap to enter a date" and in LO we see an ugly, empty box. But I guess your main point is that the other items choose functionality over beauty, so why not do the same for the checkboxes? Well, that's one reason why I posted my patch - anyone who wants to take responsibility for the change can take the code, clean it up, and submit it. :-) My biggest concern is with the spacing used (to prevent layout regressions), and I think I covered that OK in my example patch. Probably a good addition would be to center the control in the available space.
Tamás do you have any thoughts on Checkbox Context Control?
Hello Luke, Justin L, Tamás, Is the issue fixed in master after the recent MSForms fixes done by Tamás ?
(In reply to Xisco Faulí from comment #17) > Hello Luke, Justin L, Tamás, > Is the issue fixed in master after the recent MSForms fixes done by Tamás ? It's not fixed as I know. Only the date picker content control is touched. (and the legacy form fields earlier)
*** Bug 118236 has been marked as a duplicate of this bug. ***
*** Bug 147356 has been marked as a duplicate of this bug. ***
These are clickable since: https://cgit.freedesktop.org/libreoffice/core/commit/?id=c53d3a1f4b8430507d54f5fac336870df7a700af author Miklos Vajna <vmiklos@collabora.com> 2022-04-29 08:12:25 +0200 committer Miklos Vajna <vmiklos@collabora.com> 2022-04-29 09:03:01 +0200 commit c53d3a1f4b8430507d54f5fac336870df7a700af (patch) sw content controls, checkbox: add DOCX import Thanks Miklos!