Bug 108547 - When moving to insert a new record, unbound controls should not get cleared
Summary: When moving to insert a new record, unbound controls should not get cleared
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Base (show other bugs)
Version:
(earliest affected)
5.3.3.2 release
Hardware: All All
: medium enhancement
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: Database-Forms
  Show dependency treegraph
 
Reported: 2017-06-15 05:06 UTC by Howard Johnson
Modified: 2017-11-05 23:46 UTC (History)
1 user (show)

See Also:
Crash report or crash signature:


Attachments
Example database to demonstrate the issue (12.31 KB, application/vnd.sun.xml.base)
2017-06-15 05:06 UTC, Howard Johnson
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Howard Johnson 2017-06-15 05:06:58 UTC
Created attachment 134042 [details]
Example database to demonstrate the issue

Only bound fields should get cleared.

How to demonstrate:

1) Open the attached simple database, then open Form1 in Edit mode.  

Notice that the list box is not bound to any field in the underlying table.  (Right click on the List Box control (the first control) and select Control..., then select the Data tab, and verify that the Data field... is empty.)


2) Now switch out of design mode so you can watch this List Box's behavior.  

Select any value in the List Box (either 1 or 2 in this example).

Currently there are only 2 records in the underlying table.  So first move the record pointer forward one step from ID=0 to ID=1 (using the right arrow in the record navigator), and notice that the List Box value is not affected.

Also move the record pointer backwards from ID=1 to ID=0, and notice the List Box value is again not affected.

But now move to a new record, either by moving forwards past ID=1, or by clicking the new record navigator button.

Now even though the List Box is not bound to a record field, it gets cleared.

Now it would make sense if it got cleared if it was bound to a field, but it is not bound.  I don't think the List Box should get cleared.

___________________________________________
Sometimes it's very useful to have some controls on the screen that are not bound to the underlying record and can be static or independent of the underlying record data.

One example of such use would be a pull down to select or filter records using macros.  I use both of these.  But the trouble is that when using the pull down to filter the underlying records, the filter selector gets wiped out when moving to a new record.

Why do I use a pull down to filter rather than a sub-form?  Because in my accounting form I want to be able to select a particular account, or all accounts, and I don't think using sub-forms does this as well.

_____________
Tested both on HSQLDB 1.8 & MariaDB via MySQL/JDBC connection.
Linux
Comment 1 Robert Großkopf 2017-06-15 14:14:41 UTC
Could confirm this behavior. All fields will be refreshed when switching to new record. There is no difference between bounded and not bounded fields.

This feature-request must have the possibility to switch fields, which aren't bounded to a form, between "refresh field if new record" and "don't refresh field if new record".

You could, as workaround, put the field, which shouldn't refresh, to a second form beside the first form.
Comment 2 Howard Johnson 2017-06-16 04:48:34 UTC
In reply to robert

> You could, as workaround, put the field, which shouldn't refresh, to a
> second form beside the first form.

Interesting idea. Thanks Robert.  I appreciate your help.


I implemented it and it works for my current needs. 


Unfortunately it makes the design more complicated, in my mind unnecessarily complicated, now having to keep track of 2 forms.  

And this additional complexity also introduces a new minor issues, in that a user might try to move the record pointer forward while focus is on the lookup list box, and this doesn't make any sense.


My # one goal in submitting reports here is to hopefully help the next guy use Base more easily.  I have found so many rough edges on Base that made it unnecessarily hard to use.

The list box, perhaps the most important control to help put the 'relational' word in a relational database, is full of issues.  For example, it can't cut and paste, does not allow multiple columns, has the ID as the 2nd field when it should probably be the first (left most), does not easily select items by typing without chaos, is almost unusable on narrow width fields, and transposes Abc into ABc when you want Abc, but ABc is also found.

Combo Box is not much better, and is actually worse in that it can't handle more than one field at a time so it is almost totally useless at editing relations.

I suspect, unfortunately, that these rough edges and many more are a good part of the reason Base is not used that much, as I think it is otherwise a quite capable tool!

How do I conclude that Base is not used that much?  I have watched many people ask Base questions at ask.libreoffice.org, but even though they get reasonably good and prompt answers I don't see them return.  I can't imagine that they are continuing to use Base, especially because there are no further question coming from them.  Yes a few do use Base.

I have stuck w/ Base because I want to have a reasonable alternative to Access that is not owned by MS and that I can use on Linux.  To that end I hope to help do what I an can, which at the moment is to report issues I am having in using Base, and try to make good suggestion to improve it.  I admit that I'm not right all of the time.  But I do have almost 40 years of database experience starting with ISAM on an IBM 370 mainframe, and I know what Access 2003 can easily do, and I see no reason Base should not be able to at least meet that bar.  It doesn't have to do it the same way, but it does need to be able to easily handle relational data.

So I think unless someone can come up with a solid reason why unbound fields should be cleared, in my mind this remains an unnecessary rough edge in Base.