Some check boxes not working

[Maaz]

Hi there,
I am relatively new to OpenOffice. I have made a form which includes multiple check boxes. However, many of the check boxes don't work. They have the exact same properties.
I have attached the document here.

[Villeroy]

I found check boxes 50, 52, 54-57 not working. Deleting one and replace it with a copied working one results in a dead check box. When I move a dead box to another place it works. It behaves as if something invisible is covering the dead boxes but I don't find anything. Bringing a dead box to front changes nothing.

[RoryOF]

@Villeroy: deleting the tab in front of checkbox 50 moves it to the left and allows it be checked. I have not verified this for the other non-working checkboxes. Navigator shows nothing apart from two tables.

I'm going offline now.

[John_Ha]

I have attached the document here.

Thank you. It makes it so much easier to diagnose when we have the actual file

@Villeroy: deleting the tab in front of checkbox 50 moves it to the left and allows it be checked.

I noticed that where the author had used spaces to move the boxes to the right those boxes worked. However the check boxes to the left work even without spaces in front of them

I don't think it is the presence of the tab which is the problem because when I add a space in front of the check box it makes it work even with the tab still there. It is very inconsistent and looks like a bug but I am not diagnosing it further on Christmas Day.

The simplest workaround is therefore to add a space in front of each non-working check box or, preferably, in front of each check box "just in case".

If only users would use View > Non printing characters ..., they would be able to solve their own problems

View > Non printing characters ..., makes it easy to diagnose the problem.
Spaces are shown as dots in the centre of the character space. Tabs are shown as arrows.

[Villeroy]

If only users would use View > Non printing characters ..., they would be able to solve their own problems

The form controls should work anyway. I think it's a bug. I removed all leading space and created a paragraph style with 4mm indent for all the paragraphs with form controls. This repaired most of the check boxes but not all. In some places I replaced a space in front of a check box with a colon and I removed all spaces in front of check boxes in favour of tabulators.
If you tab through the form controls and use the space key to toggle the status, all check boxes do work.

[John_Ha]

I am sure it is a bug.

I looked at the XML and I could not see the space I added so that confused me.

I went into Design Mode and stretched the box associated with to the immediate left of 44 until I could see its title Check box. The box worked.

box 44 stretched a lot in design mode

box 44 stretched.gif (6.91 KiB) Viewed 2877 times

I reduced the stretch until the box was just slightly larger than originally and it still worked. Note the dotted grey line to right of the working box when selected. Clicking on the grey line selects/deselects the box.

box 44 only slightly stretched in design mode

box 44 slightly stretched.gif (5.15 KiB) Viewed 2877 times

So I think the problem is do with the size of the "area shown by green handles in Design Mode". If it is too small the box does not work. It must be a bug.

I tried reducing the font from 12pt to 10pt but it had no effect.

[John_Ha]

I am now pretty sure it is a "rounding error" problem.

I see svg=-0.1008in in the XML and I wondered if there is a minimum of 0.100000in for this value? The 0.0008in could easily get lost in rounding.

Working always with the box to the left of 44 I replaced the space preceding the box with spaceqwspace. The box now did not work. Removing the last space to give spaceqw allowed the box to work. Now, the box location (it is Anchored AS a character) is highly dependent on the preceding character. Without knowing how AOO deals with the XML it reads it is difficult to say more.

Why did the boxes work when the form was originally designed but not now? My guess is that the user was then using mm as units and the XML was written with mm. The user is now using inches and the conversion between mm and inches could cause the rounding errors. This could be why, in general, the first box (and sometimes the second box) on the line works but the ones further to the right do not - the rounding errors have accumulated as AOO add distances from the left page margin. Similarly if the left margin was changed it could cause different rounding errors making some boxes not work.

When I set my units to inches the box at 44 is shown as being Width = 0.17 inches. I cannot change it to 0.172in and changing it to 0.175in causes it to jump to 0.18in so it appears the resolution is 0.01in. When I increased the width from 0.17in to 0.18in the box worked.

So the advice to the user is to increase all box sizes to 0.18in and preferably to 0.2in.

Showing that a problem has been solved helps others searching so, if your problem is now solved, please view your first post in this thread and click the Edit button (top right in the post) and add [Solved] in front of the subject.

[RoryOF]

John: out of curiosity, would changing measurement unit to points or twips (twentieth of a point) solve the problem?

[John_Ha]

Rory

I don't think so - you will still get the problem whatever units you use though it may be in different places.

On further reflection I realised that Maaz is not using check boxes in the manner in which the designers designed them to be used and this is the root cause of the problem.

In the image below I have stretched the green handles so you can see that a check box is actually "a square to put the tick in and some text to label the box where the label text is to the right of the box".

The default font for the Label text is Arial 12 point regular but this is too big - Maaz is using Verdana 6 point text on the page. Instead of using the check box properties to change the font Maaz decided to reduce the box width to just the box and use "text on the page" to add the label. Unfortunately it appears that there is a certain minimum width (probably not documented) for the check box item to work properly and Maaz set the width to be very close to this minimum width. As a consequence some work and some don't according to how all the widths on the page add up and get rounded.

The solution remains to increase the width of each check box item to above this minimum.

This is a common problem with software. If you ever decide to use any software in a way which is different from how it is intended to be used you are very likely to run into undocumented problems because the developers did not expect you to do this and the software has never been tested to do this.

[RoryOF]

Rory

I don't think so - you will still get the problem whatever units you use though it may be in different places.

My thinking is that the units I proposed - point = 1/72 inch, 3 times finer than a millimetre (roughly!), and allows a resolution of 0.05 pt (1/20 of a point = 1 twip) - might avoid the rounding problem by the finer divisions used.

I agree with your finding about the irregular use of the checkboxes - being Christmas, I didn't give any deep thought to that, except to think that as the document uses several "arrays" of checkboxes and associated labels, a generic table might be designed with all the checkboxes in appropriate columns and their labels in adjoining cells, and this "table template" used for each occurrence of a checkbox "array" (quotes used around "Array" and "Table template", as these terms are not used in their normal OO sense).

[John_Ha]

Try this repaired file where I edited the XML and used Search/Replace to change 270+ instances of 0.1713in to 0.2in. This allowed the left of the "C" of Check box to be visible so I changed all the labels "Check box" to "%%%%%Box" where % is a space.

A better change would have been to use the correct label text set as Verdana 6 in the Check box properties so the box width is much wider.

Note that when you click on a box you now see a thin grey box outline to the right which you did not see before.

Clipboard01.gif (7.72 KiB) Viewed 2809 times

OpenOffice Form_wider items.odt

(48.01 KiB) Downloaded 115 times

[DiGro]

Took another look at the check boxes.
It seems odd that there is something special needed to make it work without problem.
A checkbox should probably be not much more than that. Show me a check or don't
Why wouldn't it work then ? ( Not taking into account the solution of John_Ha)

Could it be because all of the check boxes are named Check Box 1 ? (and there are a lot of them)
Checked it by changing the names from the obvious numbered choices to CB_001 to CB_215.

Nope, that wasn't the issue. Nothing changed, still boxes that didn't work.

OK, changed all the labels of the check boxes to the option mentioned after the check box (as mentioned by John ((Verdana 6 pt)
That made it work. All boxes for the choices working as they should. However some others didn't and there it wasn't that easy to change.

Left me with the question: Why should I enter a label if I don't gonna use it anyway ?
The options to check are mentioned behind the check boxes, so why do I need a label ?

I removed all labels "Check Box" from the check boxes and the problem disappeared.
All boxes for the choices are now working as they should.
They also tab neatly to the next one and not showing the cursor next to the check box.

It seems that, in this case, not entering a label makes the check box work as suspected.
Show a check mark or don't.
Maybe in other cases labels are needed and can be added as John mentioned to make it work.

I did not fix the entire file and all text boxes also, but just the obvious numbered choices and some others

Working boxes

[John_Ha]

It seems odd that there is something special needed to make it work without problem.

There isn't ... as long as you use it as the developers designed it to be used which uses the Check box Label field to label it so it increases the item width.

We aren't developers so we have no idea of the constraints and restrictions which caused the developers to do what they did. We are users like you and we try to get you working with a workaround if necessary. I refer you to my comment:

This is a common problem with software. If you ever decide to use any software in a way which is different from how it is intended to be used you are very likely to run into undocumented problems because the developers did not expect you to do this and the software has never been tested to do this.

What "made it work" in your solution was increasing the width of the item. Everything else can be ignored (and you need to distinguish between Name and Label - they are different things). See Chapter 15 - Using Forms in Writer in the Writer Guide.

Edit: A thought? A wild guess? Maybe the developers thought that the minimum width of the item would always be "width of box plus gap to first character of label text at the font size specified". Your box was then narrower than this minimum. On second thoughts this is almost certainly what the developers did as the label text will need to be separated from the box by a varying distance which is label-font-size dependent - the bigger the font used for the label text the bigger the gap needed. Placing a "virtual space" between box and Label will achieve this.

Showing that a problem has been solved helps others searching so, if your problem is now solved, please view your first post in this thread and click the Edit button (top right in the post) and add [Solved] in front of the subject.

[John_Ha]

As you can see, when you use the check box "as designed" AOO quite sensibly encloses the Label field in a dotted rectangle when the user ticks or unticks the box to make sure the user reads only the appropriate label text related to that box. The user realises that, in my example, with box label Fred, the text the user responds to is "Fred" and is not "Fred 44. Klosett:"