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
@David : please only file one report per issue - the localisation bug and the overwrite bug are two separate things.
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.
Note that this doesn't occur in Version: 4.4.5.2 Build ID: a22f674fd25a3b6f45bdebf25400ed2adff0ff99 Locale: fr.UTF-8 ==>> regression
Could you attach test file (an ODB file containing at least one form and referencing several hundred records.) ? Thank you
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.
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
(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.
Created attachment 119670 [details] Example with internal database - move to end in the form.
(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.
(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
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.
(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...)
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.
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 4f5fe008a3d5f0b5ddfa656299306cff9d57d802 source 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
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 ...
(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.
Thanks raal and sorry, my fault, you are absolut right,... its early in Sunday ;-)
Migrating Whiteboard tags to Keywords: (bibisected) [NinjaEdit]
*** Bug 97460 has been marked as a duplicate of this bug. ***
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)
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
Bump. Bug still persists in 5.1.1.3
Version must correspond to earliest version the bug can be found.
Bug does not appear in any version 4 builds.
HOORAY !!! FIXED IN 5.1.2 THANKS GUYS AND GALS.
NOPE ... False alarm ... sorry. Garbled info still appearing. :(
*** Bug 99382 has been marked as a duplicate of this bug. ***
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?
Tomaz: It seems ApplySettings isn't called in vcl/source/window/dockingarea.cxx, did I miss something?
*** Bug 103894 has been marked as a duplicate of this bug. ***
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.
(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
@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
*** Bug 109535 has been marked as a duplicate of this bug. ***
*** Bug 109536 has been marked as a duplicate of this bug. ***
*** Bug 113000 has been marked as a duplicate of this bug. ***
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.
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
*** Bug 114999 has been marked as a duplicate of this bug. ***
https://gerrit.libreoffice.org/49621
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.
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.
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