Problem description: In the Form I change one of the values using listbox. Then I change field to textbox filled with multiple lines "Long Text". As I type the dikette remains grey and from the start You cannot save changes to database. I use mysql with jdbc connection. I changed to new driver but nothing changes. This error lasts since openoffice (It worked exactly the same). Steps to reproduce: 1. Open form 2. Change one of the values 3. Change Long Text database type Text Field in Form. 4. See if diskette of the navigation below remains grey. Current behavior: You cannot save changes in some fields beacause Libre Office base does not see that it's changed. Expected behavior: All the changes are noticed by Libre Office base and you can save data changes Operating System: Windows 7 Version: 3.6.5.2 release
Can't confirm this behavior with LO 3.5.7 and LO 4.0.3.1. Have created a "Long Text"-field, also an input-field in a form. Could change the content. The button for saving the new content will be activated, when the content has been changed. LO 3.6.* is not available at this time at my PC. My system: OpenSUSE-Linux 32bit rpm-Linux.
It's not 100% reproducible. It happens like 1/10 times. Additionally it happens on Win 7 32 bit, Win 7 64bit, OpenOffice, Libre Office - all versions. One common thing is the database server: MySQL 5.1.48-community running on Windows XP. Everything else has changed. We use several computers to connect to this database. On all computers it is the same. Once it happens You may type as long as You want but diskette is always grey and You can't save changes. After changing to next record and back again tha data remains from before the typing. One more thing: It also happens to normal VARCHAR fields, but long text is the worst case.
Created attachment 78321 [details] Form Navigator screenshot - form structure I attach additionally the structure of the form as form navigation screenshot.
Piotr: when you tell "Libre Office - all versions", do you mean you also tried last one, 4.0.2? (BTW 4.0.3 will be released in a few days)
Version 4.0.2 -> No. I did not try version 4 at all. I'm not sure if it is stable enough - sorry. But is there a serious chance that something in this matter has changed?
4.0 is a major version. Now I can't assure the bug won't appear in 4.0.2 but this version is the recommended one. You may also wait for the 4.0.3 which will be released in few days as I said in my previous comment. Moreover, you could give a try to some days for the test. It could be interesting to know if the bug is still there or not. Now it's up to you :-)
Today I installed Libre Office 4.0.2.2 and..... The bug is still there :( By the way I noticed that 100% reproduction is to enter the record FOR THE FIRST TIME, press button (I assigned macro to open file folder connected with the record) and going to text field, libre does not recognize changes. Another observation is that I set a trigger (BEFORE UPDATE) in my database to insert a record in additional table every time the trigger is called (so when the main record is updated). Observation: After such situation no record is added (so the record in mysql database is never touched by Libre)
Lionel: reading the last Piotr's comment, it makes me think about fdo#63398 (I put it in see also), is it right?
not quite: 1) It exists in all versions I know (not only 4) and openoffice. 2) I set the trigger IN THE DATABASE (not in the forms) 3) It happens not only if Macro is running. Before I had no macros at all in my forms and it still happened. I can switch the macros off -> it is the same. I have also a feeling that it happens mostly when the form is in the background for a while (and particularly my macro openning file folder always put form in the background because it opened another application).
(In reply to comment #7) > By the way I noticed that 100% reproduction is to enter the record FOR THE > FIRST TIME, press button (I assigned macro to open file folder connected > with the record) and going to text field, libre does not recognize changes. You found a way to always reproduce? Great! That will allow us to reproduce the bug ourself and hopefully to fix it. However, I don't understand your reproduction instructions. Please clarify: - "enter record FOR THE FIRST TIME": is that adding a new record, as opposed to editing (modifying) an existing one? - "press button": press what button? - could you please attach a MySQL dump of an affected database and the .odb file used to connect to it? You can obviously create a "fresh" database with dummy data, if you don't want to show us / the whole world you data. As long as you get the issue with the database with the dummy data :) (I don't think it is related to bug 63398.)
Created attachment 79059 [details] test_db_mysql OK!!! I managed to set up completely new simple database and form in LO and have exaclty the same effect :)))) How to: 1) Must have JDBC class in path 2) STart attached file for test database. 3) Enter password "lK2%hH1!", user "sql28360" should be stored - some free mysql server on freemysqlhosting.net 4) Start form "ed klient" - the only one 5) change record pointer in the upper table to anything else but first record (only once!!! do not touch anything else) 6) Press a button to open information service on internet (I put www.onet.pl). It is not even a macro. 7) Internet browser opens. Take your time during browsing different pages. It must last for a while (1-2 minutes is enough) 8) with ALT-TAB return to the form 9) Not touching anything else start typing in the bottom field "Additional info" and observe the diskette button on bottom panel ;) Keep the fingers crossed that reproduction works for You!
one more thing I forgot: If the bottom text field "Additional info" is below the screen move the screen BEFORE pressing the button. Do not touch ANYTHING ELSE after switch back to the form beside starting typing into this text field.
(In reply to comment #11) Cannot immediately reproduce on LibreOffice 3.5 on Debian GNU/Linux amd64. > 5) change record pointer in the upper table to anything else but first > record (only once!!! do not touch anything else) There are several ways to do that, and maybe this happens with only one of them? - Click in the "left margin" of a record, selecting the whole record. The status line of the table says e.g. "Record 3 of 4 (1)". - Click in the first data column of a record, selecting only that cell (one column of one row). The status line of the table says e.g. "Record 3 of 4" - Use the arrows in the status line of the table. - Type a number in the status line of the table; where it says "1", e.g. put "3" - Use the arrow keys of the keyboard to go down - Press TAB repeatedly until one changes record > 6) Press a button to open information service on internet (I put > www.onet.pl). It is not even a macro. I still don't understand what button I'm supposed to push. I don't see any "out of the ordinary" button in the form, and I don't understand how a button on the form would open a website without a macro. > 9) Not touching anything else start typing in the bottom field "Additional > info" and observe the diskette button on bottom panel ;) So I have to click in the "add_info" field to put focus in it? (In reply to comment #12) > one more thing I forgot: If the bottom text field "Additional info" is below > the screen move the screen BEFORE pressing the button. For me, if I do that, the form moves back to top when I go back to ut and I have to scroll again.
Created attachment 79075 [details] additional_explanation Lionel, I send additional explanation in form of screen shot with comments. For me it is 100% reproducible in this case. In ma case it is VERY important bug because people use the button to open specific outside information and than type it in database, but after all it is missing!! Maybe it happens only on windows?? Is there a way to record screen?
I can confirm this bug. The following happens: You get back to the form. You move through the form with tabulators. You click with the mouse in the field "add_info". The counter of navigation-bar shows row 2 of 4 (I have chosen row 2 in the tablecontrol of the mainform). Notice: the counter doesn't change to the subform; in the subform is only row 1 of 1. The Input of the field "add_info" isn't noticed by the form, because the GUI is waiting for an input in the mainform. When moving with the tabulator through the form I notice, that every field of the subform is shown with row 2 of 4. You couldn't change everything in the subform, because the the GUI doesn't notice, that the cursor is in the subform. So this isn't a special bug of a special text-field. It's a bug of recognizing the position of the cursor when getting inside a form from other windows by Alt Tab. My System: OpenSUSE 12.3 32bit rpm. So I will change the platform to "All". Also I could reproduce it with LO 3.3.4, LO 3.6.62. So I will change the Version to LO 3.3.4. Could be a bug since the beginning of LO.
Robert -> Thanx! I change the importance to high, because it leads to DATA LOSS and occurs at every platforms. I thought it can be a specific bug on my database but it seems it affect most of the systems (maybe not everybody even notices that data is lost). From the time I added the buttons (which always takes focus out of the form) it is very serious problem. The buttons had to make work easier, but lead to additional problems...
Created attachment 79085 [details] Form with subform, built in database, same bug This isn't a special bug of MySQL. I have created a database with two tables. The tables are connected with a 1:1-relation. There are 4 rows in the table of the mainform. Every row of the mainform could only show one row of the table in the subform. Now open the form. Press the button, which doesn't have any function. The navigation-bar changes from "row 1 of 4" to "row 1 of 1". It has been changed to the subform. Now press the tabulator-key. The cursor enters the first field of the subform. But at the same moment the navigation-bar changes to "row 1 of 4". Write something in the textfield. It couldn't be saved.
OK, reproduced on 3.6 and 4.0 (my development trees). Step 5 is not necessary for me, neither is "take your time", I can go directly back to the form after browser opens. Also, bug is still reproducible if I change the button's action to "None". The crucial step seems to be to exit focus of MainForm to a button in SubForm. If I move the button to the MainForm, then bug is not reproducible anymore.
I add listbox. Button or listbox causes the same effect. As for listbox only touching without changing value will cause this effect.
Caused by the fix to https://issues.apache.org/ooo/show_bug.cgi?id=51621 When clicking on the button, in FmTextControlShell::controlActivated, m_aControlActivationHandler is not called, because the button does not serve any SFX slots, so "not useful to put the form shell on top of the stack". Execution continues and the button's "got focus" method activates the its datafrom (subForm). So far so good. However, when giving focus to a text control, m_aControlActivationHandler is called, the form shell is not on top of the stack, so it is put there. Which has as side-effect to activate the top dataform (main)... which is the wrong one, since the text area belongs to the subform, not main. By contrast, when moving directly to the text control, _aControlActivationHandler is called, which (re)activates the top (main) dataform and *after* that the subform is activated.
Lionel Elie Mamane committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=7fd1cc18130464a9f09cb7a866e88c4d52e4716d fdo#63695 revert hackish fix to i#51621 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.
Lionel Elie Mamane committed a patch related to this issue. It has been pushed to "libreoffice-4-0": http://cgit.freedesktop.org/libreoffice/core/commit/?id=66ca50016b8a65e67269026ca5b456fa4f8fa35e&h=libreoffice-4-0 fdo#63695 revert hackish fix to i#51621 It will be available in LibreOffice 4.0.4. 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.