Issue 93457 - allow a "Tristate" property for check box grid columns, and set it to "No" upon creating a check box for a required field
Summary: allow a "Tristate" property for check box grid columns, and set it to "No" up...
Status: CLOSED FIXED
Alias: None
Product: Base
Classification: Application
Component: code (show other issues)
Version: OOO300m3
Hardware: All All
: P3 Trivial (vote)
Target Milestone: ---
Assignee: marc.neumann
QA Contact: issues@dba
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2008-09-04 09:26 UTC by Frank Schönheit
Modified: 2017-05-20 10:33 UTC (History)
2 users (show)

See Also:
Issue Type: ENHANCEMENT
Latest Confirmation in: ---
Developer Difficulty: ---


Attachments
document to reproduce the bug case (9.69 KB, application/vnd.sun.xml.base)
2008-09-04 09:27 UTC, Frank Schönheit
no flags Details

Note You need to log in before you can comment on or make changes to this issue.
Description Frank Schönheit 2008-09-04 09:26:53 UTC
- open the attached database document
- open the contained form, or the contained table, by doubling it
- in the table data view (resp. in the table control within the form), there's
  a check box column which is bound to a table field which is declared as
  NOT NULL (aka "Entry Required" = "Yes" in the table designer)
- repeatedly click onto the check box in the current row, cycling through
  its possible values this way
=> the cycle is "checked", "undetermined", "not checked"

The "undetermined" state does not make sense at all, in case the bound table
column is required - in such a case, trying to update the row will result in an
error message from the database.

Well, that's not completely true. There's one case where it could make sense to
use an "undetermined" value for the check box: If there is a server-side default
value for this table column. However, comparing how often users are
confused/annoyed by a checkbox which wrongly allows NULL values, with how often
there are server-side defaults for boolean columns, and considering that in such
a case the easy workaround would be to simply set the respective default value
in Base's table design, too, I'd say that changing the current behavior is the
better alternative.
Comment 1 Frank Schönheit 2008-09-04 09:27:35 UTC
Created attachment 56216 [details]
document to reproduce the bug case
Comment 2 Frank Schönheit 2008-09-18 21:50:39 UTC
better idea:
Given that check box form controls have a "Tristate" property, which can be set
to "Yes" or "No", we should allow this property for check box columns, too.
Then, when a table control column is created for a table/query column which is
defined to be NOT NULL, "Tristate" will automatically be set to YES, and to NO
otherwise. This should hold for both table control columns in the form designer,
and for columns in the table data view.
Comment 3 Frank Schönheit 2008-09-18 22:33:42 UTC
fixed in CWS dba31c

find more information about this CWS, like when it is available in the master
builds, in EIS, the Environment Information System:
http://eis.services.openoffice.org/EIS2/cws.ShowCWS?Path=DEV300%2Fdba31c
Comment 4 Frank Schönheit 2008-11-04 12:23:29 UTC
adjusting summary to reflect what in fact has been changed in the course of this
issue.
Comment 5 Frank Schönheit 2008-11-04 13:46:55 UTC
fs->msc: please verify in CWS dba31e
Comment 6 marc.neumann 2008-11-14 09:57:59 UTC
verified in CWS dba31e

find more information about this CWS, like when it is available in the master
builds, in EIS, the Environment Information System:
http://eis.services.openoffice.org/EIS2/cws.ShowCWS?Path=DEV300%2Fdba31e
Comment 7 drewjensen.inbox 2009-07-21 16:29:40 UTC
@fs - checked this with DEV310m_15
Tristate property is now available
However - reading your summary the behavior is not as described. It is always
set to NO without regard to whether the field accepts null (is required).

This can be an issue if creating a form for a table with existing data..well put
up an example db/form later today.
Comment 8 drewjensen.inbox 2009-07-21 21:23:42 UTC
A little more information:

The dataview appears to be working as described.

The problem is with checkbox control when added to a form, either in a grid
column or as a separate control. Using the form wizard or adding the control
directly does not affect it either, same situation both ways.

You can see the issue with the bug doc. Set the boolean field to Nullable, set
the default value to NULL.

Create a form based on the table with the wizard and go directly to data input.
Now add a new record, explicitly adding data to the text field - but do not do
anything with the chechbox control. Save the record. Now check the table and you
see that the value for the boolean field is set to False.

(Note - so far only checked this on Linux, will get it checked on Windows also
just to be sure it isn't a platform specific problem)
Comment 9 Frank Schönheit 2009-08-12 09:51:27 UTC
Ah, the wizard ....

This issue indeed didn't touch the wizard at all. What was implemented here is
that the TriState property is available for check box grid columns, and that
they have a reasonable default when they're created via DnD of a table field.
Seems I completely missed the wizard here. Can we agree to submit a new issue
for this?