Bug 94341 - Total record number overwritten in record toolbar control on form
Summary: Total record number overwritten in record toolbar control on form
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Base (show other bugs)
Version:
(earliest affected)
5.0.1.2 release
Hardware: All All
: high major
Assignee: Mike Kaganski
URL:
Whiteboard: target:6.1.0
Keywords: bibisected, bisected, regression
: 97460 99382 103894 109535 109536 113000 114999 (view as bug list)
Depends on:
Blocks: Database-Forms
  Show dependency treegraph
 
Reported: 2015-09-18 14:26 UTC by David
Modified: 2018-02-17 18:35 UTC (History)
19 users (show)

See Also:
Crash report or crash signature:


Attachments
Image showing the errors set out in the description (129.39 KB, image/jpeg)
2015-09-18 14:26 UTC, David
Details
a test database using HSQLDB 1.8 and a form which shows the bug. (2.85 MB, application/zip)
2015-10-15 18:17 UTC, David
Details
Example with internal database - move to end in the form. (287.75 KB, application/vnd.oasis.opendocument.database)
2015-10-16 09:22 UTC, Robert Großkopf
Details

Note You need to log in before you can comment on or make changes to this bug.
Description David 2015-09-18 14:26:26 UTC
Created attachment 118826 [details]
Image showing the errors set out in the description

Hi ...

I use base for a number of databases, and when viewing a table in form view, the number showing the total number of tables is corrupted.  It seems it is trying to show two (or more) values at the same time.

Another issue is that the Form view of the table data has a french title in the Window's title bar.  I don't speak French and my PC is set to English (New Zealand).

Those are the issues I wish to report.  Thank you for looking into these issues.  And thanks for a great office suite.

Best regards,

David.

PS.  I'm not sure that the image has uploaded as an attachment, so here is a link to the image on imgur.  The image shows the problems described above.

http://imgur.com/SmiFM6p
Comment 1 Alex Thurgood 2015-09-18 16:11:23 UTC
@David : please only file one report per issue - the localisation bug and the overwrite bug are two separate things.
Comment 2 Alex Thurgood 2015-09-18 16:20:07 UTC
The record toolbar shows the number of records with regard to whatever the form is based on (query, table, etc).

I see the overwrite bug on

Version: 5.0.1.2
Build ID: 81898c9f5c0d43f3473ba111d7b351050be20261
Locale : fr-FR (fr.UTF-8)

How to reproduce :

1) Open an ODB file containing at least one form and referencing several hundred records.

2) Open the form.
3) Use the record tool bar to navigate from record 1 to record 3, one record at a time.
4) Now, click on the double arrow to move to the last record.
5) Observe that the value of the current record selected gets overwritten by another value.
Comment 3 Alex Thurgood 2015-09-18 16:32:44 UTC
Note that this doesn't occur in

Version: 4.4.5.2
Build ID: a22f674fd25a3b6f45bdebf25400ed2adff0ff99
Locale: fr.UTF-8

==>> regression
Comment 4 raal 2015-10-09 07:23:54 UTC
Could you attach test file (an ODB file containing at least one form and referencing several hundred records.) ? Thank you
Comment 5 David 2015-10-15 18:17:28 UTC
Created attachment 119648 [details]
a test database using HSQLDB 1.8 and a form which shows the bug.

1. Unzip the testDB to drive C on your PC.  
2. Adjust the java path in the batch file "runServer-TestDB.bat".  
3. Then using the batch file, run the HSQLDB database.  It will run in server mode. 
4. Open the ODB file.
5. Open the CADASTRO form.
6. Click to go ahead one record (from 1 to 2).
7. Click to go to the last record.  It may take several seconds to come up.

8. The total record number in the toolbar should be jumbled.  If it's not, then reduce the size of the form until the record fields are cut off by the form's edge.  i.e. the fields will be PARTIALLY outside the scroll area of the form.
9. Go to first record, 
10. Go to last record.  The problem should show up.

For me, no resizing is necessary.  The problem seems to faithfully reproduce itself.  However, I did manage to get it to come up without being garbled by creating a new form from the Table Data.  But that only happened once.  The second time, it came up garbled as expected.
Comment 6 raal 2015-10-15 19:46:53 UTC
LO 5.0.2.2, win7 crashes when I click on form CADASTRO

Version: 5.1.0.0.alpha1+
Build ID: 2511a21841dd9dec735a53add8174e47d24deb88
TinderBox: Win-x86@62-merge-TDF, Branch:MASTER, Time: 2015-10-13_23:26:46
Error when click on form CADASTRO:
The connection to the data source "TestDB" could not be established.
Error code: 1000
The driver class 'org.hsqldb.jdbcDriver' could not be loaded.
Error code: -1
org/hsqldb/jdbcDriver
Comment 7 Robert Großkopf 2015-10-16 09:21:08 UTC
(In reply to raal from comment #6)

> The driver class 'org.hsqldb.jdbcDriver' could not be loaded.
> Error code: -1
> org/hsqldb/jdbcDriver

It's an external HSQLDB, which is attached. I have created an example with internal HSQLDB. Only one table of a database and one form for this table.
Comment 8 Robert Großkopf 2015-10-16 09:22:21 UTC
Created attachment 119670 [details]
Example with internal database - move to end in the form.
Comment 9 David 2015-10-16 13:50:47 UTC
(Please view this text with any monospaced font to preserve formatting).

  //////////////////////////////////////////////////////////
 /// HOW TO ACCESS THE EXTERNAL DATABASE WITH L.O. BASE ///
//////////////////////////////////////////////////////////

Here are the instructions again to run the test database as a server and then access it with the ODB file.  The error saying that the driver was not found was because L.O. was not set up correctly.  Please follow these instructions to set up L.O. and run the database.
 

START HERE:
-----------
1. Unzip the testDB to drive C on your PC.  

RUN THE DATABASE IN SERVER MODE:
--------------------------------
2. Adjust the java path in the batch file "runServer-TestDB.bat".  (See foot note 2).
3. Then using the batch file, run the HSQLDB database.  It will run in server mode. 

CONFIGURE L.O. TO ACCESS THE EXTERNAL DATABASE
----------------------------------------------
4. Open LibreOffice, and click on TOOLS > OPTIONS > LIBREOFFICE (tab) > ADVANCED (tab)
5. Select a 32-bit java installation.  (See foot note 5).
6. Add the HSQLDB.jar to the classpath. Click the button CLASSPATH, then ADD ARCHIVE.  Navigate to the HSQLDB.jar provided.  Click OPEN, then OK. (See foot note 6).

OPEN THE TESTDB.ODB FILE
------------------------
7. Open the ODB file.
8. Open the CADASTRO form.

CHECK FOR THE BUG
-----------------
9. Click to go ahead one record (from 1 to 2).
10. Click to go to the last record.  It may take several seconds to come up.

11. The total record number in the toolbar should be garbled.  If it's not, then reduce the size of the form until the record fields are cut off by the form's edge.  i.e. the fields will be PARTIALLY outside the scroll area of the form.
12. Go to first record, 
13. Go to last record.  The problem should show up.

For me, no resizing is necessary.  The problem seems to faithfully reproduce itself.  However, I did manage to get it to come up without being garbled by creating a NEW form from the Table Data.  But that only happened once.  The second time, it came up garbled as expected.



PLEASE READ THESE FINAL COMMENTS:
---------------------------------
It is of great value to run BASE against an external database since that is where BASE really shows it's power.  Since the reporting in Base is a little limited, it has been better for me to run an external database as a SERVER so that reporting tools like iReport and JasperStudio can produce reports that can incorporate subreports, and all kinds of formatting, easily.  

Another idea would be to incorporate Jasper reporting and iReport Report editing into BASE ... since they are open source.  This would allow the use of sub reports, which I believe, the current reporting tool does not allow.  


I trust these few instructions and comments have been useful.  Don't hesitate to contact me should you encounter any further problems.

Yours sincerely,

David.


Foot note for Number 2:
-----------------------
Use any pure text editor to edit the batch file.  You can use Notepad or something similar.  I prefer Notepad++.  Change the line that says:
path = "C:\Program Files\Java\jdk1.8.0_60\bin"
Change the path to the one of your own java installation.  The one mentioned here is a 64-bit installation.  For more info on 32-bit or 64-bit installations, see foot note 5.  Please note that LibreOffice requires a 32-bit java installation for step five.  If you don't have a 32-bit java installation on your system, you will need to download one and install it to be able to complete step five.

Foot note for Number 5:
-----------------------
You will know that the Java installation selected is 32-bit because it will be installed in a program directory with (x86) somewhere in the middle of the directory name like this ... "C:\Program Files (x86)\Java\jre1.8.0_60".  A directory like this ... "C:\Program Files\Java\jre1.8.0_60" will be a 64-bit installation ... so don't use that one.  It also works well with Java 7 32-bit.

Foot note for Number 6:
-----------------------
It is the same jar that ran the server.  Do not use the (HSQLDB.jar)s with numbers in the jar names.  This is only for me to swap into a more recent version of HSQLDB for testing ... which hasn't been successful ... so I've stayed with 1.8 which works great.
Comment 10 Robert Großkopf 2015-10-16 14:46:29 UTC
(In reply to David from comment #9)

Why do you write all this here? Do you think the bug appears only with external HSQLDB?

A bug-description should use the simplest way to reproduce the bug. And the simplest way for all users to get an example is to use the internal database. There must nothing else be installed - only LO must be used with the internal database for reproducing the bug.

Regards

Robert
Comment 11 David 2015-10-16 15:45:31 UTC
There is nothing else installed.  Just the JRE and LO, which is standard.  Just because it is an external database does not mean that there is other software installed.  The setup in question is using the same HSQLDB as LO uses, the only difference is that it is external.  This is an LO BASE feature and should work as such.  If it can be reproduced with an internal DB, then cool!  But if it is a bug only with an external DB, then that is how it should be reproduced.  I announced the bug and I only use OL Base with HSQLDB in server mode, rather than in embedded mode.  The only difference is the MODE that HSQLDB is being run in, nothing else.

I wrote the long explanation because I was kinda surprised that there were issues getting the DB running in server mode.  That kinda stuff is in the manual and its a key feature.  It seemed to me that the person trying to reproduce the bug was not familiar with setting up BASE in this fashion ... hence the detailed explanation.  I also needed a detailed explanation to getting BASE to run this way the first time.  

I guess to solve this bug, the server mode operation needs to be checked and seen to be resolved ... otherwise further bug reports will be filed.
Comment 12 Lionel Elie Mamane 2015-10-16 16:02:43 UTC
(In reply to David from comment #11)

David, see comment 7 and 8. Robert has reproduced the issue with embedded HSQLDB.

In general, when reporting a bug, it is preferable to try to make the smallest / easiest reproduction case possible; this helps the developer taking up the bug to focus on what's wrong rather than a lot of fluff around.

Also recognise that some people use LibreOffice only connecting to an ODBC database, or only to a PostgreSQL (native connector) database or ... These people would not have any clue on how to setup HSQLDB in server mode. You mention some kind of manual, I'm not sure what manual you are speaking about.

In general, we sorely miss people with a good knowledge of LibreOffice Base to triage bugs. Would you be interested in using your expertise towards that?

(If you know C++, we also miss people to *fix* bugs...)
Comment 13 David 2015-10-16 17:37:54 UTC
Thank you for your comments.  I understand what you are saying.

I come from an OpenOffice background and have used it since version 2.  So the documentation I referred to is really OpenOffice material.  I can try to find the said documentation and add it to LibreOffice documentation if you wish.  That would be the part on using HSQLDB as an external database, rather than internal, so as to be connectable to external reporting tools such as iReport and JasperStudio.  If I can't find the existing material, I could write a tutorial if that is what you would like.  Someone can contact me if this is what is needed.

I program in Java.  I have done so for a good many years now.  But I haven't tried my hand at C++.  I've heard it has a good many similarities.  Contributing to LO code would be nice.  Maybe one day I'll get there.
Comment 14 raal 2015-10-19 05:24:17 UTC
This seems to have begun at the below commit.
Adding Cc: to Tomaž Vajngerl ; Could you possibly take a look at this one? Thanks

adc374975884cb8763bea04c39dffad212f42d49 is the first bad commit
commit adc374975884cb8763bea04c39dffad212f42d49
Author: Norbert Thiebaud <nthiebaud@gmail.com>
Date:   Thu Jul 9 22:37:03 2015 -0700

    source sha:4f5fe008a3d5f0b5ddfa656299306cff9d57d802

    source sha:4f5fe008a3d5f0b5ddfa656299306cff9d57d802

author	Tomaž Vajngerl <tomaz.vajngerl@collabora.co.uk>	2015-05-22 08:51:44 (GMT)
committer	Tomaž Vajngerl <tomaz.vajngerl@collabora.co.uk>	2015-05-23 09:55:39 (GMT)
commit	4f5fe008a3d5f0b5ddfa656299306cff9d57d802 (patch)
use ApplySettings instead of ImplInitSettings is called
Comment 15 riesslibo 2015-11-01 08:45:27 UTC
Hi all,
can confirm this effect/behaviour on my own Base Application with the 5.0.1.2 with Win and internal HSQL-DB.

No new informations about the bug, it is described in whole in the comments above, just a confirmation that this strange behaviour occured in my Base applciation with the new version, too (and not before LO v5)

Thanks
Lothar

PS: perhaps the next one who can confirm should change it to "confirmed"? Not sure, if I'm entitlet to do so ...
Comment 16 raal 2015-11-01 08:55:25 UTC
(In reply to riesslibo from comment #15)
> 
> PS: perhaps the next one who can confirm should change it to "confirmed"?
> Not sure, if I'm entitlet to do so ...

Status "NEW" means confirmed.
Comment 17 riesslibo 2015-11-01 09:01:53 UTC
Thanks raal and sorry, my fault, you are absolut right,... its early in Sunday ;-)
Comment 18 Robinson Tryon (qubit) 2015-12-13 11:14:31 UTC Comment hidden (obsolete)
Comment 19 raal 2016-02-01 22:08:44 UTC
*** Bug 97460 has been marked as a duplicate of this bug. ***
Comment 20 Dennis 2016-02-09 13:52:31 UTC
Confirmed 
https://youtu.be/kLWRC1EnTh4

version
Version: 5.0.4.2
Build ID: 1:5.0.4~rc2-0ubuntu1~trusty1
Locale: en-US (en_US.UTF-8)
Comment 21 Dennis 2016-02-11 13:50:30 UTC
screen grab of mangling still in 
Version: 5.1.0.3
Build ID: 5e3e00a007d9b3b6efb6797a8b8e57b51ab1f737
CPU Threads: 4; OS Version: Linux 3.19; UI Render: default; 
Locale: en-US (en_US.UTF-8)


http://i.imgur.com/2cVqzjW.png
Comment 22 David 2016-03-19 17:44:37 UTC
Bump.

Bug still persists in 5.1.1.3
Comment 23 Julien Nabet 2016-03-19 17:47:54 UTC
Version must correspond to earliest version the bug can be found.
Comment 24 David 2016-03-22 19:21:24 UTC
Bug does not appear in any version 4 builds.
Comment 25 David 2016-04-09 12:48:10 UTC
HOORAY !!!

FIXED IN 5.1.2

THANKS GUYS AND GALS.
Comment 26 David 2016-04-09 12:50:58 UTC
NOPE ...

False alarm ... sorry.

Garbled info still appearing.  :(
Comment 27 raal 2016-04-19 05:20:22 UTC
*** Bug 99382 has been marked as a duplicate of this bug. ***
Comment 28 grgsmiths 2016-09-12 16:38:57 UTC
Adding this comment 2016 09 12
 in hopes this bug can be fixed soon...

I am using Win10 home 64bit and jdk-8u101-windows-x64  Java and LO v5.2.1.2 64bit
and I can confirm that this bug reported 2015 09 16 still exists

I have been learning the LO Base to use it for non profit organizations
and this bug is certainly one that could be overlooked for some
but not for others...

At the least it makes it hard to read how many records are in a table 
especially when using subforms etc
and using the Form Navigation View provided in LO 

My question:
Is it being addressed by someone to fix it in a new version of LO?
Comment 29 Julien Nabet 2016-09-13 19:45:25 UTC
Tomaz: It seems ApplySettings isn't called in vcl/source/window/dockingarea.cxx, did I miss something?
Comment 30 Robert Großkopf 2016-11-13 07:27:28 UTC
*** Bug 103894 has been marked as a duplicate of this bug. ***
Comment 31 Bert 2016-12-09 13:53:28 UTC
Using LO 5.1.6.2 with the bug still there.
But... when you maximize your form window the total number of records shows correctly. Also when you minimize it and go back to the form. So, what it needs is a refresh of the screen, and then it's ok. 

I hope this helps to solve it.
Comment 32 Ejay 2017-02-03 11:49:03 UTC
(In reply to Bert from comment #31)
> Using LO 5.1.6.2 with the bug still there.
> But... when you maximize your form window the total number of records shows
> correctly. Also when you minimize it and go back to the form. So, what it
> needs is a refresh of the screen, and then it's ok. 
> 
> I hope this helps to solve it.

Upgraded to LO 5.2.5.1 and bug is still there
Indeed,when you maximize total number is shown correct.
However if you then add a new record the bug returns
You have to always resize and remaximize the window record after record
Comment 33 Alex Thurgood 2017-02-03 12:05:44 UTC
@Ejay : please do not change the version number field, as this represents the version in which the problem was first determined. Resetting to 5.0.1.2
Comment 34 Alex Thurgood 2017-07-28 07:07:29 UTC
*** Bug 109535 has been marked as a duplicate of this bug. ***
Comment 35 Alex Thurgood 2017-07-28 07:09:06 UTC
*** Bug 109536 has been marked as a duplicate of this bug. ***
Comment 36 Robert Großkopf 2017-10-08 18:52:38 UTC
*** Bug 113000 has been marked as a duplicate of this bug. ***
Comment 37 Qomplainerz 2017-11-17 19:25:40 UTC
I still have the same problem in 5.4.2.
I have a table with a little bit more than 300 records.
It usually happens when I open the form and browse from record 1 of 300, to 2 of 300 etc. First it shows Record x of 87, then it updates to record x of 100+ and then you can't read the total records anymore. Resizing the form window a little bit makes it clean again, but when it loads the next few records it happens again. And surprisingly it does NOT happen when I look at record x of y in the table itself.
Comment 38 Stang 2017-12-23 23:44:09 UTC
This bug is still present in Beta of:

Version: 6.0.0.1
Build ID: d2bec56d7865f05a1003dc88449f2b0fdd85309a
CPU threads: 4; OS: Linux 4.8; UI render: default; VCL: gtk2; 
Locale: en-US (en_US.UTF-8); Calc: group
Comment 39 Robert Großkopf 2018-01-14 16:25:20 UTC
*** Bug 114999 has been marked as a duplicate of this bug. ***
Comment 40 Mike Kaganski 2018-02-13 08:16:16 UTC
https://gerrit.libreoffice.org/49621
Comment 41 Commit Notification 2018-02-13 10:27:23 UTC
Mike Kaganski committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=179fbaf3687fc40d75a2570639191f797f03ce4e

tdf#94341: Set child transparent mode for ToolBox

It will be available in 6.1.0.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 42 Stang 2018-02-14 16:49:36 UTC
Have tested with:

Version: 6.1.0.0.alpha0+
Build ID: 3c913c3844acae8ee0d80ab174133bdc7677efea
CPU threads: 4; OS: Linux 4.13; UI render: default; VCL: gtk2; 
TinderBox: Linux-rpm_deb-x86_64@70-TDF, Branch:master, Time: 2018-02-14_01:29:59
Locale: en-US (en_US.UTF-8); Calc: group

This has corrected the problem.


Thank you for your attention to this matter.
Comment 43 christian_kuhn 2018-02-17 18:35:24 UTC
Hello,

I have tried it with 

Version: 6.1.0.0.alpha0+ (x64)
Build ID: 05986e7f98ea1c0bd8092500968774ef3f6bcef4
CPU threads: 1; OS: Windows 6.1; UI render: default; 
TinderBox: Win-x86_64@42, Branch:master, Time: 2018-02-17_01:32:28
Locale: de-DE (de_DE); Calc: Group

It was ok.

Best regards,
Christian