Bug 163889 - Cannot replace style of cell A1 when cursor is in cell A1
Summary: Cannot replace style of cell A1 when cursor is in cell A1
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
Inherited From OOo
Hardware: All All
: medium minor
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: Find&Replace-Styles
  Show dependency treegraph
 
Reported: 2024-11-14 03:19 UTC by Saburo
Modified: 2024-11-20 06:17 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:


Attachments
Demo document (9.04 KB, application/vnd.oasis.opendocument.spreadsheet)
2024-11-17 15:39 UTC, BogdanB
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Saburo 2024-11-14 03:19:33 UTC
Description:
When trying to replace a cell style in the "Find and Replace" dialog, if the cursor is in cell A1, the style of cell A1 cannot be replaced.

Steps to Reproduce:
1.Enter ”AAA” in Sheet1.A1
2.Apply style “Heading 1”
3.Ctrl + H
4.Check "Cell styles"
5.Find: “Heading 1”, Replace: “Accent 1”
6.[Find Next]-->[Replace]

Actual Results:
Search key not found

Expected Results:
The "Accent 1" style will be applied to sheet1.A1.


Reproducible: Always


User Profile Reset: No

Additional Info:
Click anywhere outside cell A1 and then click the [replace] button to succeed.

Version: 24.2.7.2 (X86_64) / LibreOffice Community
Build ID: ee3885777aa7032db5a9b65deec9457448a91162
CPU threads: 4; OS: Windows 10.0 Build 19045; UI render: Skia/Raster; VCL: win
Locale: ja-JP (ja_JP); UI: ja-JP
Calc: CL threaded
Comment 1 mkt 2024-11-14 05:23:51 UTC
Hi,

It seems like the whenever the [Replace] button is clicked, LO is looking for the next cell with "Heading 1" to apply "Accent 1" instead of applying to the current cell. Therefore, it is showing "Search key not found".

If there are 2 cells with "Heading 1", keep clicking [Replace] button would apply "Accent 1" to the second cell then to the first cell.

I could reproduced this with version:
Version: 24.8.2.1 (X86_64) / LibreOffice Community
Build ID: 0f794b6e29741098670a3b95d60478a65d05ef13
CPU threads: 2; OS: Windows 10 X86_64 (10.0 build 19045); UI render: Skia/Raster; VCL: win
Locale: en-US (en_US); UI: en-US
Calc: threaded
Comment 2 Xisco Faulí 2024-11-14 09:39:20 UTC
it works if AAA is added to B2 instead of A1
Comment 3 Xisco Faulí 2024-11-14 09:54:05 UTC
Hi Mike,
I'm wondering if this issue is caused by a loop starting as position 1 instead of 0
Comment 4 Mike Kaganski 2024-11-14 20:00:09 UTC
I don't really know. The code pointer is ScTable::SearchStyle (sc/source/core/data/table6.cxx), which in turn calls ScColumn::SearchStyle (sc/source/core/data/column.cxx); but which of them is faulty, needs investigation (one already suspicious bit is immediate increment of nRow in the former function, before the first call to the latter; but maybe that's OK).
Comment 5 BogdanB 2024-11-15 06:26:21 UTC
(In reply to Mike Kaganski from comment #4)
> I don't really know. The code pointer is ScTable::SearchStyle
> (sc/source/core/data/table6.cxx), which in turn calls ScColumn::SearchStyle
> (sc/source/core/data/column.cxx); but which of them is faulty, needs
> investigation (one already suspicious bit is immediate increment of nRow in
> the former function, before the first call to the latter; but maybe that's
> OK).


I am note sure by this, but nRow (which is zero) is increased before search in sc/source/core/data/table6.cxx:

//nRow here is zero
nRow += nAdd; 
648
        do
649
        {
650
//nRow here already is one
            SCROW nNextRow = aCol[nCol].SearchStyle( nRow, pSearchStyle, bBack, bSelect, rMark );
651
            if (!ValidRow(nNextRow))
Comment 6 BogdanB 2024-11-17 06:54:23 UTC
I moved line:
            nRow += nAdd;
from line 647 to 651, after the nRow is called, and this bug is solved.
Comment 7 BogdanB 2024-11-17 07:07:04 UTC
I will make more tests for different scenarios, and if everything will be ok, I will come with a commit.
Comment 8 BogdanB 2024-11-17 13:29:27 UTC
I tried with a matrix of 3*3 cells (first 9 cells from the sheet), enter any text, mark with Heading 1 Style, move the selected cell outside the matrix, Ctrl+H, Check Cell Styles and deselect "Selection" if is checked, and when replaced with Accent 1, the first column is not replacing. Just everything else. So, a similar problem could be with column number initialization.
Comment 9 BogdanB 2024-11-17 15:39:40 UTC
Created attachment 197663 [details]
Demo document

(In reply to BogdanB from comment #6)
> I moved line:
>             nRow += nAdd;
> from line 647 to 651, after the nRow is called, and this bug is solved.

So, particularly for this exact bug case, this change would solve the case, BUT, for this document I will attach, not.

Just open the file, place the cursor on yellow cell, and replace with Ctrl+H, "Cell styles", “Heading 1” with “Accent 1”.

You will notice that the first column is not included when Replace is actioning.
Comment 10 BogdanB 2024-11-17 15:46:24 UTC
I studied this bug with my matrice of 9 cells in 24.8. If you have the A1 selected, and press repeatedly Replace, first cell is passed and not replaced, than all the others are replaced, then, the last one, A1, is replaced, also. But if there is just one cell to be replaced, this is not working.

Version: 24.8.3.2 (X86_64) / LibreOffice Community
Build ID: 48a6bac9e7e268aeb4c3483fcf825c94556d9f92
CPU threads: 16; OS: Linux 6.8; UI render: default; VCL: gtk3
Locale: ro-RO (ro_RO.UTF-8); UI: en-US
Calc: threaded
Comment 11 BogdanB 2024-11-20 06:14:11 UTC
I found that this style is not even search for.
In my matrix, I replaced A1 with Heading 1, and all other with Heading 2. The cursor on A1. Find next is not finding anything, despite the cursor being exactly where the result should be.

In sc/source/core/data/table6.cxx, ScTable::SearchStyle has a 
bool bSelect = rSearchItem.GetSelection(); -> this is "false" after passing, like no selection have been made.

If I select 2 cells, bSelect is "true".

I supose click on a cell is not considered selection, in this case.
Comment 12 Mike Kaganski 2024-11-20 06:17:07 UTC
Note that we don't discuss the code in Bugzilla: we use gerrit for that. You create a change, send it to review, and then we discuss the issues there. The change doesn't have to be complete, even doesn't have to compile.