Bug 151919 - Forms - Tablecontrol: Content of numeric fields becomes invisible when moving cursor from new row to rows above
Summary: Forms - Tablecontrol: Content of numeric fields becomes invisible when moving...
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Base (show other bugs)
Version:
(earliest affected)
7.1.0.3 release
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: Caolán McNamara
URL:
Whiteboard: target:24.2.0 target:7.6.3
Keywords: bibisected, bisected, regression
Depends on:
Blocks:
 
Reported: 2022-11-05 11:31 UTC by Robert Großkopf
Modified: 2023-09-26 15:31 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:


Attachments
Open the forms - move cursor from new row to other row and back to new row twice. (11.98 KB, application/vnd.oasis.opendocument.database)
2022-11-05 11:31 UTC, Robert Großkopf
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Robert Großkopf 2022-11-05 11:31:19 UTC
Created attachment 183426 [details]
Open the forms - move cursor from new row to other row and back to new row twice.

Open the attached database.
Open the form.
There are two table controls, both with the same content.

Set cursor in new row of the first table control.
Switch from new row to an existing row.
Switch back to new row.
When switching back a second time to an existing row content in every numeric field will disappear if cursor is set in this field. 
Changing a field, which doesn't show the real content, to NULL is impossible.

Do the same with the second table control.
Bug doesn't appear, because the fields with numeric values are created as "formatted field".

You could see the difference of the fields when opening the form for editing, not for input data. Right mouse click on the column header → column. Title of the appearing dialog show which kind of column has been created: "Numeric Filed" or "Formatted Field".

Bug appears in LO 7.4.2.3, but also in earlier versions. First installed version where bug appears here is LO 7.1.0.3. Doesn't appear in LO 7.0.5.2 on OpenSUSE 15.3 64bit rpm Linux.
Comment 1 jcsanz 2022-11-09 12:17:17 UTC
I can confirm the bug

Note that the number doesn't disappear, just is not shown while the cursor is on the field, but if you change to another field, reappears.

Tested with:
-------------
Version: 7.4.2.3 (x64) / LibreOffice Community
Build ID: 382eef1f22670f7f4118c8c2dd222ec7ad009daf
CPU threads: 4; OS: Windows 10.0 Build 19045; UI render: Skia/Raster; VCL: win
Locale: es-ES (es_ES); UI: es-ES
Calc: CL
-------------
Version: 7.2.7.2 (x64) / LibreOffice Community
Build ID: 8d71d29d553c0f7dcbfa38fbfda25ee34cce99a2
CPU threads: 4; OS: Windows 10.0 Build 19045; UI render: Skia/Raster; VCL: win
Locale: es-ES (es_ES); UI: es-ES
Calc: CL
Comment 2 Robert Großkopf 2022-11-09 14:24:16 UTC
(In reply to jcsanz from comment #1)
> I can confirm the bug
> 
> Note that the number doesn't disappear, just is not shown while the cursor
> is on the field, but if you change to another field, reappears.

But the result will be the same: You couldn't set this field to NULL by removing any content of the field. 'Disappear' seems to be the wrong word in English. Content will be invisible when receiving focus and will be visible, when loosing focus.
Comment 3 raal 2023-04-19 16:39:33 UTC
error message in terminal: Focused object has invalid index in parent

This seems to have begun at the below commit in bibisect repository/OS linux-64-7.1.
Adding Cc: to Caolán McNamara ; Could you possibly take a look at this one?
Thanks
 417ff811c5a60f8e8ac39dd1d4ab81a3f6e7b9a3 is the first bad commit
commit 417ff811c5a60f8e8ac39dd1d4ab81a3f6e7b9a3
Author: Jenkins Build User <tdf@pollux.tdf>
Date:   Mon Jul 6 22:56:24 2020 +0200

    source d5b3c5d5093c56e748610a3972fc90b1521ae9e3

97896: weld DbNumericField item | https://gerrit.libreoffice.org/c/core/+/97896
Comment 4 Caolán McNamara 2023-09-26 09:39:54 UTC
I think what happens is we just blank the text of the control when in a "new row" and on moving back we may have the same *value* as the previous row so don't reformat even though the text was blanked out.
Comment 5 Commit Notification 2023-09-26 11:33:19 UTC
Caolán McNamara committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/9b7c732215f2dc34d1f0cfc08ea912a3925b13b0

Resolves: tdf#151919 mark blanked fields as requiring a reformat

It will be available in 24.2.0.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 6 Caolán McNamara 2023-09-26 11:34:04 UTC
done in trunk, backport to 7-6 in gerrit
Comment 7 Commit Notification 2023-09-26 15:31:22 UTC
Caolán McNamara committed a patch related to this issue.
It has been pushed to "libreoffice-7-6":

https://git.libreoffice.org/core/commit/6f2dda05b8808729716a22e9f98ae28b03094ecb

Resolves: tdf#151919 mark blanked fields as requiring a reformat

It will be available in 7.6.3.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.