Created attachment 112416 [details] Open "Form_tablecontrol" - event "Text modified" happens without modifying anything Looking for some bugs with events, which should be executed in a form. Open the attached database. Macros must be allowed. There are two forms. Both are connected to the same table. "Form" is created with standalone-fields, "Form_tablecontrol" is created with a tablecontrol and the fields inside the tablecontrol. In both forms the event "Text modified" of the field "Name" is linked to a macro, which should only show a message 'Event happened'. Open "Form_tablecontrol". The event happens, but no text has been modified. Go to next row (navigationbar). The event happens again, but no text has been modified. Open "Form". No event happens. Go to next row (navigationbar). No event happens. Expected behavior: Event "Text modified" should only happen when modifying thext, not while loading a form or moving from one row to another, or, for example, click somewhere in the row (happens also).
I can confirm with Version: 4.5.0.0.alpha0+ Build ID: 88562ee6e352b5446bb55e906e8f1c2f34035a49 TinderBox: Linux-rpm_deb-x86_64@46-TDF, Branch:master, Time: 2015-01-16_23:58:11
Same buggy behavior if "Text modified" is linked to a numeric field or a formatted field.
Created attachment 112565 [details] bt when clicking on a cell On pc Debian x86-64 with master sources updated today, I could reproduce this. I attached a bt.
I'm not so sure about this... When navigating from one record to the next, the text in the field changes, so seen from the POV of the control, in some sense launching the "TextChanged" event is correct. Similarly, when loading the form, the text is initialised, and thus changes from empty to something, and again in some sense the "TextChanged" event is correct. On the other hand, one can make a case that changes-through-navigation "don't count". However, I agree that the control gaining focus is definitely *not* the right time for the TextChanged event. That's a bug. Also, the fact that the behaviour is different in a grid (table control) and with a plain control is most definitely a bug. It should be the same in both cases. (In reply to Julien Nabet from comment #3) > Created attachment 112565 [details] > bt when clicking on a cell Is that bt when changing the current record or when moving from one column to another within the same row? Looks like it is when changing the current record. What would be interesting would be to compare with the plain control case; how is the event "blocked" there? 1) My expectation is that frm::OBoundControlModel::setControlValue is still called. 2) But then, a "normal" TextBox should have a method similar to DbCellControl::_propertyChanged and/or DbCellControl::implValuePropertyChanged. Is that also called? I expect so. 3) Edit::SetText is also called, I expect. 4) In the grid case, we have the FmXGridCell that listens (registered for the event), and thus the event gets delivered. 5) What happens in the case of a plain control (not in a grid)? Did the equivalent of FmXGridCell stop listening, or does it get the event but just decide to ignore it? To investigate that, it will probably be useful to get a backtrace of when the event *does* happen to a plain control, that is when editing the text. What is then the path from Edit::SetText to whatever treats the event? Where in the path (and why) is the event "ignored" when gaining focus, and when moving to next / previous control? 4) So, if my assumptions are correct, where in the chain between Edit:: SetText and FmXEditCell::onTextChanged is the event "blocked" so that it does not happen? > > On pc Debian x86-64 with master sources updated today, I could reproduce > this. > I attached a bt.
(In reply to Lionel Elie Mamane from comment #4) > 4) So, if my assumptions are correct, where in the chain between Edit:: > SetText and FmXEditCell::onTextChanged is the event "blocked" so that it > does not happen? That part I forgot to delete... I wrote it before I realised that FmXEditCell is specific to grids.
Created attachment 112617 [details] bts I attached 2 bts (one when clicking on same line, the other when clicking the other line). I haven't managed yet to retrieve a bt with the other form even if I tried these breaks: FmXEditCell::onTextChanged() at /home/julien/compile-libreoffice/libreoffice/svx/source/fmcomp/gridcell.cxx:3794 FmXGridCell::OnWindowEvent(VclWindowEvent*) at /home/julien/compile-libreoffice/libreoffice/svx/source/fmcomp/gridcell.cxx:3402 FmXGridCell::LinkStubOnWindowEvent(void*, void*) at /home/julien/compile-libreoffice/libreoffice/svx/source/fmcomp/gridcell.cxx:3398 Edit::SetText(rtl::OUString const&) at /home/julien/compile-libreoffice/libreoffice/vcl/source/control/edit.cxx:2641
Lionel Elie Mamane committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=08bdb40656898fc484f5200b63610a31369ddd87 fdo#88551 no need to update content from field when activating grid cell It will be available in 4.5.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.
Hmmm... The whole grid has a single controller, which explains the behaviour: the text that the controller controls has changed (because the controller switched to a different column or row), so from its POV "TextChanged" event makes sense. That makes sense from an implementation POV, but indeed leads to unexpected and not-that-useful event behaviour. With standard controls, each control has its own controller, and the problem does not arise. The situation with TextChanged when changing cell (column) within the same row is now fixed. The situation when changing row may be a bit more complicated.
** Please read this message in its entirety before responding ** To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present on a currently supported version of LibreOffice (5.0.5 or 5.1.0) https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the version of LibreOffice and your operating system, and any changes you see in the bug behavior If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a short comment that includes your version of LibreOffice and Operating System Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to "inherited from OOo"; 4b. If the bug was not present in 3.3 - add "regression" to keyword Feel free to come ask questions or to say hello in our QA chat: http://webchat.freenode.net/?channels=libreoffice-qa Thank you for your help! -- The LibreOffice QA Team This NEW Message was generated on: 2016-02-21
Bug appears also in the first available LO-version (LO 3.3.0.4, OpenSUSE 42.1 64bit rpm Linux). So I set this bug as "Inherited From OOo".
** Please read this message in its entirety before responding ** To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present on a currently supported version of LibreOffice (5.2.5 or 5.3.0 https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the version of LibreOffice and your operating system, and any changes you see in the bug behavior If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a short comment that includes your version of LibreOffice and Operating System Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to "inherited from OOo"; 4b. If the bug was not present in 3.3 - add "regression" to keyword Feel free to come ask questions or to say hello in our QA chat: http://webchat.freenode.net/?channels=libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug-20170306
Dear robert, To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
Bug is still the same with Version: 6.4.0.0.beta1 Build ID: 4d7e5b0c40ed843384704eca3ce21981d4e98920 CPU threads: 6; OS: Linux 4.12; UI render: default; VCL: kf5; Locale: de-DE (de_DE.UTF-8); UI-Language: en-US Calc: threaded
Dear Robert Großkopf, To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from https://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://web.libera.chat/?settings=#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
Bug has been gone with Version: 7.1.0.3 / LibreOffice Community Build ID: f6099ecf3d29644b5008cc8f48f42f4a40986e4c CPU threads: 6; OS: Linux 5.3; UI render: default; VCL: kf5 Locale: de-DE (de_DE.UTF-8); UI: de-DE Calc: threaded Was still there with LO 7.0.5. I will set this one to WORKSFORME