Bug Hunting Session
Bug 88552 - Event "Text modified" never happens in a combobox inside a tablecontrol
Summary: Event "Text modified" never happens in a combobox inside a tablecontrol
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: Database-Forms
  Show dependency treegraph
 
Reported: 2015-01-18 10:06 UTC by Robert Großkopf
Modified: 2019-09-29 19:53 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:


Attachments
Type text in the combobox of "Form_tablecontrol" - event 'modifyed' will never happen. (22.29 KB, application/vnd.oasis.opendocument.base)
2015-01-18 10:06 UTC, Robert Großkopf
Details
bt with debug symbols (9.80 KB, text/plain)
2019-09-29 17:00 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 10:06:29 UTC
Created attachment 112417 [details]
Type text in the combobox of "Form_tablecontrol" - event 'modifyed' will never happen.

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 "Hobby" is linked to a macro, which should only show a message 'Event happened'. The field "Hobby" is created as a combobox.
Open "Form_tablecontrol". Write something in the column "Hobby". No event happens.
Open "Form". Write something in the field "Hobby". With every changed character the event happens.

Expected behavior: Event "Text modified" should happen when modifying the content of the combobox. Works as expected in a normal form. Doesn't work in a tablecontrol.
Comment 1 Alex Thurgood 2015-01-19 14:18:32 UTC
Confirming on 
Version: 4.3.5.2
Build ID: 3a87456aaa6a95c63eea1c1b3201acedf0751bd5

OSX 10.10.1
Comment 2 QA Administrators 2016-02-21 08:35:08 UTC Comment hidden (obsolete)
Comment 3 Robert Großkopf 2016-02-21 09:13:06 UTC
Bug still exists with LO 5.1.1.1, OpenSUSE 42.1 Leap, 64bit rpm Linux.
Comment 4 Robert Großkopf 2016-03-05 10:54:11 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 5 QA Administrators 2017-03-06 15:08:57 UTC Comment hidden (obsolete)
Comment 6 Robert Großkopf 2017-03-07 15:56:53 UTC
Bug still exists with LO 5.3.1.1, OpenSUSE 42.1 Leap, 64bit rpm Linux.
Comment 7 QA Administrators 2018-03-08 03:44:15 UTC Comment hidden (obsolete)
Comment 8 Robert Großkopf 2018-03-09 07:00:50 UTC
Bug still exists with LO 6.0.2.1, OpenSUSE 42.3 Leap, 64bit rpm Linux.
Comment 9 QA Administrators 2019-09-25 03:00:20 UTC Comment hidden (obsolete)
Comment 10 Robert Großkopf 2019-09-25 14:47:04 UTC
Bug still exists with LO 6.3.2.1, OpenSUSE 15 Leap, 64bit rpm Linux.
Comment 11 Julien Nabet 2019-09-29 12:23:23 UTC
Robert: how did you assign macro in tablecontrol form?

I found the way for not tablecontrol one but I don't know how to select one of the field of the tablecontrol.
Comment 12 Robert Großkopf 2019-09-29 15:23:00 UTC
(In reply to Julien Nabet from comment #11)
> Robert: how did you assign macro in tablecontrol form?
> 
> I found the way for not tablecontrol one but I don't know how to select one
> of the field of the tablecontrol.

Open the form for editing.
Right mouse click on the column-header of "Hobby".
Go to "Column ..."
Now you can change the events of the column "Hobby".
Comment 13 Julien Nabet 2019-09-29 17:00:37 UTC
Created attachment 154641 [details]
bt with debug symbols

Thank you Robert for your feedback, I could find the option.

I attached bt corresponding at the moment LO displays the popup with non tablecontrol form.
Thought it may help to compare situation with tablecontrol form.
Comment 14 Julien Nabet 2019-09-29 19:20:14 UTC
In OK case, we got here:
    277     if ( maTextListeners.getLength() )
    278         maTextListeners.textChanged( e );
    279 }
see https://opengrok.libreoffice.org/xref/core/toolkit/source/controls/unocontrols.cxx?r=bb16f659#278

not in KO case.
Indeed, maTextListeners is empty with KO case.

In OK case, maTextListeners is filled with 4 calls to 
    281 void UnoEditControl::addTextListener(const uno::Reference< awt::XTextListener > & l)
    282 {
    283     maTextListeners.addInterface( l );
    284 }
see https://opengrok.libreoffice.org/xref/core/toolkit/source/controls/unocontrols.cxx?r=bb16f659#283
Comment 15 Julien Nabet 2019-09-29 19:53:24 UTC
Not clear for me all this mechanism of events and attachments works.
Depending on the form we open, it seems we got completely different objects to handle.