Apache OpenOffice (AOO) Bugzilla – Full Text Issue Listing
|Summary:||"Cycle = 'Active Record'" is ignored by table controls, they always proceed to the next record when TABbing out of the last column|
|Component:||code||Assignee:||AOO issues mailing list <issues>|
|Status:||CONFIRMED ---||QA Contact:|
|Issue Type:||DEFECT||Latest Confirmation in:||---|
Description mhatheoo 2009-10-10 16:02:06 UTC
Having set the form-properties / data / cycle set to "record" (german: aktueller Datensatz) the content will be upted anyway (silently) when moving from last to first field in TAB-order. as this is done - to this cycle-type - silent and unintentionally, this is an issue. Martin
Comment 1 drewjensen.inbox 2009-10-10 23:45:28 UTC
Checked with an Embedded HSQLdb database on Go-OO 3.0.1, OO.o 3.1.1, DEV300m_59 / Ubuntu 9.0.4 OO.o 3.1.1, DEV320m_1 / Win 7 Using a detail form for a single record and setting: Allow Modifications = Yes Cycle = Active Record [EN_us] Filter = Automatically forces the user to explicitly commit changes (click on next/prev record, save, restore or close form w/confirming dialog). Tabbing cycles from last to first control without a commit. Two places where Cycle property does not preclude a quite commit: With a grid control the Cycle property has no effect as a tab from the last column always moves to the first column in the next row and this triggers the save. A form with multiple result sets (Master/Sub Form for instance) will save the data if a tab moves from one result set to another. (One dataform to another).
Comment 2 drewjensen.inbox 2009-10-10 23:55:08 UTC
Created attachment 65291 [details] Embedded form Details/Dues_no_add has the Cycle set Active Record
Comment 3 mhatheoo 2009-10-11 19:03:43 UTC
(..) Automatically forces the user to explicitly commit changes (click on next/prev record, save, restore or close form w/confirming dialog) (..) not in here no dialog pops up (how should it look like?) TAB and NAV-icons on NAV-bar will all store/update immidiatly And sorry, TAB does not move to first column/field in the very but to first in next record. Martin
Comment 4 drewjensen.inbox 2009-10-11 20:01:16 UTC
@martin - OK, so on your installation if you download the attached database opening the form Details/dues_no_add Edit a value and use tab repeatedly it does not cycle form the last datacontrol to the first without saving the data? If not then let me know which OS and which version of OO.o you are using so that I can try to setup the same here.
Comment 5 mhatheoo 2009-10-12 03:03:01 UTC
yes, it DOES safe I tried the form Family-Info and set cycle to record (germ.: Aktueller Datensatz) 1. TAB cycles within the form works BUT: I see a difference: in my form the last control is a table - in yours it is an ordinary field yours is cycling correct, in mine not 2. However, the record is updated 2.a: close window will pop up save/cancel, that is okay 2.b: ESC has no function 2.c: the roll-back-icon works 2.d: NAV-key/icons will store changes without pop-up Martin OO.o 3.1.1 (310m19) on win2k with Java 6-16
Comment 6 Frank Schönheit 2009-10-23 11:50:55 UTC
> in my form the last control is a table - in yours it is an ordinary field > yours is cycling correct, in mine not so this boils down to the case Drew mentioned: when you're in a table control, then TAB cycles through the records *within* the grid control, and thus silently commits. Right? > 2. > However, the record is updated > 2.a: close window will pop up save/cancel, that is okay > 2.b: ESC has no function Do you mean ESC in the dialog which is raised when you close the window, or do you mean pressing ESC in the form itself (respectively a control therein)? I assume the latter, in this case, it'd be a different issue. > 2.c: the roll-back-icon works > 2.d: NAV-key/icons will store changes without pop-up This again sounds like you're trying to come back to issue 36231 (unless I misunderstand you), where you request no silent commit at all. Please let's keep this topic out of *this* issue here. So, if I understand all of the above right, then the "Cycle = 'Active record'" property works fine for you, *except* when a table control is involved. Correct?
Comment 7 mhatheoo 2009-10-24 04:10:23 UTC
==>fs no, it neither works for me nor for you: 1.case: it does not work, when last control in form is a table-control 2. case: it partly works when last control is another control: a) ESC has no function (no drawback of field-entries when in form) b) cursor-key have no function (of course they should not have some) c) click on Navigation-icons saves/changes data without pop-up for confirmation ESC when for example the control is a text-field, ESC will not draw back the entries, even you are still in the field/control. This is an issue. Martin
Comment 8 Frank Schönheit 2009-11-06 19:38:15 UTC
> 1.case: > it does not work, when last control in form is a table-control Yes, that's what I said above, right? > 2. case: > it partly works when last control is another control: > a) ESC has no function (no drawback of field-entries when in form) Okay, you answered my question in some round-about way, but ... Again, this is a different issue then. http://qa.openoffice.org/issue_handling/basic_rules.html#one_per_issue explains why it is important to not mix different problems in the same issue. > b) cursor-key have no function (of course they should not have some) Then this works as expected ... > c) click on Navigation-icons saves/changes data without pop-up for > confirmation This, again, is another problem, described in an issue which we both know too well: issue 36231. It would ease things if you would not insist on mixing different problems in one issue. > ESC > when for example the control is a text-field, ESC will not draw back the > entries, even you are still in the field/control. This is an issue. A separate one. See above.
Comment 9 mhatheoo 2010-01-03 01:30:14 UTC
Funstuff it seems something has changed under the hood from 3.1.1 to 3.2, however, not to the good: it looks, that is no more possible to have a table-control in the same form with the normal-fields/controls: entering data in text-fields is stored to table but unvisible in form itself - content there is overwriten with "0", having one field in the table-control makes it immpossible to set -- coding of line -- enter data +/or set empty fields to content not Null -- entry forced etc looks like well organized confusion - however, actually ooo-base became worthless Martin
Comment 10 mhatheoo 2010-01-03 01:52:54 UTC
Created attachment 66950 [details] not intended to be here, the screenprint shows the problem