Bug 88551 - Event "Text modified" happens in tablecontrol while navigating through form without modifying anything
Summary: Event "Text modified" happens in tablecontrol while navigating through form w...
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Base (show other bugs)
Version:
(earliest affected)
Inherited From OOo
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-01-18 09:52 UTC by Robert Großkopf
Modified: 2019-12-03 15:56 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:


Attachments
Open "Form_tablecontrol" - event "Text modified" happens without modifying anything (22.26 KB, application/vnd.oasis.opendocument.base)
2015-01-18 09:52 UTC, Robert Großkopf
Details
bt when clicking on a cell (12.45 KB, text/plain)
2015-01-20 22:26 UTC, Julien Nabet
Details
bts (5.32 KB, application/x-zip)
2015-01-21 21:23 UTC, Julien Nabet
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Robert Großkopf 2015-01-18 09:52:05 UTC
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).
Comment 1 raal 2015-01-18 14:55:37 UTC
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
Comment 2 Robert Großkopf 2015-01-19 17:25:16 UTC
Same buggy behavior if "Text modified" is linked to a numeric field or a formatted field.
Comment 3 Julien Nabet 2015-01-20 22:26:21 UTC
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.
Comment 4 Lionel Elie Mamane 2015-01-21 06:39:38 UTC
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.
Comment 5 Lionel Elie Mamane 2015-01-21 06:51:01 UTC
(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.
Comment 6 Julien Nabet 2015-01-21 21:23:15 UTC
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
Comment 7 Commit Notification 2015-01-22 05:57:30 UTC
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.
Comment 8 Lionel Elie Mamane 2015-01-22 06:04:06 UTC
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.
Comment 9 QA Administrators 2016-02-21 08:36:05 UTC Comment hidden (obsolete)
Comment 10 Robert Großkopf 2016-03-05 10:58:33 UTC
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".
Comment 11 QA Administrators 2017-03-06 15:25:02 UTC Comment hidden (obsolete)
Comment 12 QA Administrators 2019-12-03 14:30:31 UTC Comment hidden (obsolete)
Comment 13 Robert Großkopf 2019-12-03 15:56:57 UTC
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