Bug 84069 - LO BASE Forms: Contents of Unbound Field Improperly Reset When Advancing Row Cursor to Insert Row
Summary: LO BASE Forms: Contents of Unbound Field Improperly Reset When Advancing Row ...
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Base (show other bugs)
Version:
(earliest affected)
Inherited From OOo
Hardware: Other All
: medium enhancement
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: Database-Forms
  Show dependency treegraph
 
Reported: 2014-09-19 01:14 UTC by Doug
Modified: 2017-11-05 22:35 UTC (History)
2 users (show)

See Also:
Crash report or crash signature:


Attachments
Base demonstration document containing Form1 described in report (10.81 KB, application/vnd.oasis.opendocument.database)
2014-09-19 01:14 UTC, Doug
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Doug 2014-09-19 01:14:03 UTC
Created attachment 106528 [details]
Base demonstration document containing Form1 described in report

1.  Open sample Form1, which internally has one MainForm bound to data source and text box control that is not bound to any data field (and so is unbounded).
2.  Click on the text box and type something.
3.  Use record selectors to advance row cursor to additional records in recordset.
4.  Unbound text box correctly retains what is typed until ...

UNEXPECTED RESULT: Unbound textbox is reset when row cursor enters insert row.  The text you typed disappears when it entered.

EXPECTED RESULT:  Unbound textbox should not be reset, should continue to say the same thing, display of data should be consistent and unaffected by entering insert row.

Unbound fields are useful for displaying reference information, but this bug means that they cannot be used for that purpose.

Workaround is to create second entire form in Form1 that is unbounded, but that also implicates another set of issues that will be subject of second bug report.
Comment 1 Alex Thurgood 2014-10-21 08:23:44 UTC
@Doug : just a quick question : does your form have any controls other than the unbound textbox ? I don't see any when I open the form in my master build.
Comment 2 Alex Thurgood 2014-10-21 08:31:24 UTC
The problem does not occur for me when the form contains at least one data bound control.

Surely, you are not suggesting that it should be possible to have a form through which one can navigate via the record toolbar, and yet not be able to visualise the data or even enter any new data ? What possible use case would envisage that ?
Comment 3 Alex Thurgood 2014-10-21 08:38:54 UTC
Even if I just try to reproduce your description, without any bound controls, the content of the unbound text box does not disappear on moving record cursor of the record navigation bar to new record.

Version: 4.4.0.0.alpha0+
Build ID: d807cba9ee60cb1404b54addf9cd3e54de89f331

OSX 10.10
Comment 4 Alex Thurgood 2014-10-21 08:41:48 UTC
Nor can I reproduce the problem on LO 4322 production release.

Which version were you using ?
Comment 5 Robert Großkopf 2014-12-30 19:10:40 UTC
What is wrong?
The textbox isn't bounded to a datafield but is content of a form. The form clears all controls when moving to a new row. The form clears not only the controls, which are bounded to a field of a table or query.

If you wish to have a unbounded textbox, open the form-navigator, click on Forms → New → Form and create a form, which isn't bounded to any data and isn't a SubForm of the MainForm.
You could set this form with 
Navigation Bar → No
and 
Cycle → Active Record
but it mustn't be done ...
Move the control "Text Box 1" into this form and the content would never been changed by anything you do in the MainForm with content, which is bounded to a table.
Comment 6 Doug 2014-12-31 00:17:07 UTC
Robert @5:  Using that workaroud, but it has implications for the record count in the navigation bar.  When you switch between fields, where the fields are on different forms with different recordsets, the record count bar would display unexpected/undesired results, showing record count of 1 on one field, and different count on another field.  That is technically correct, but would not be intuitive to typical user.  Requires further workaround of concealing navigation bar for unbounded form, but this is not ideal and I believe opened potential for more inconsistencies.

Would be better for this purpose if unbounded fields were not cleared in new record row.

Alex @3:  Issue first encountered on Fresh LO for Windows in September.  Reconfirmed just now with the attachment above on LO  4.3.5.2.0+ Build ID: 430m0(Build:2) for OpenSuse 13.2.  As noted by Robert @5, issue is an LO Base functionality.  Open form, enter text, and then browse to new record row, text just entered will disappear.
Comment 7 Robert Großkopf 2014-12-31 08:06:29 UTC
(In reply to Doug from comment #6)
> Robert @5:  Using that workaroud, but it has implications for the record
> count in the navigation bar.  

My solution in most forms: I 'm not using the navigationbar at the bottom of the window. I'm using the navigationbar as control of a form. I'm using not only subforms, also forms beneath other forms ...

> 
> Alex @3:  Issue first encountered on Fresh LO for Windows in September. 
> Reconfirmed just now with the attachment above on LO  4.3.5.2.0+ Build ID:
> 430m0(Build:2) for OpenSuse 13.2.  As noted by Robert @5, issue is an LO
> Base functionality.  Open form, enter text, and then browse to new record
> row, text just entered will disappear.

Couldn't confirm it first encountered in any LO-version. It is the same behavior here with LO 3.3.0 beta1. Have tested it also with 3.3.4 ... 
My System: OpenSUSE 12.3 64bit rpm Linux.
I will set
- Version to Inherited from OOo (because it never works in another way)
- Importance to Enhancement (at this moment it the normal behavior isn't what you wanted to have, but for other people they won't expect it in another way)
- Status to New (because I could confirm the behavior the text in the unbounded textbox would be refresh when reching new record).
Comment 8 Alex Thurgood 2015-01-03 17:40:13 UTC Comment hidden (no-value)