https://bugs.freedesktop.org/show_bug.cgi?id=88551

--- Comment #4 from Lionel Elie Mamane <[email protected]> ---
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.

-- 
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
Libreoffice-bugs mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs

Reply via email to