Often nothing happens when double clicking on find in files results

[Mario Valle]

I do a find in files search. In the results window often clicking on a result line does nothing. In the majority of cases it is the only resulting line of a file. Don’t seems there are other patterns.
Really don’t known how to collect more info on this problem. Is something that happens also to others?
Thanks for clarifying (or fixing)!
mario

[PeterJones]

@Mario-Valle ,

often clicking on a result line does nothing

Did you realize it’s double-click, not single-click, which activates the goto-file-and-line behavior?

Double-click works for me. If double-click doesn’t work for you, then you need to give us more information, including: ?-menu, Debug Info; if possible, a screenshot of the Find Result window showing your one match (if you have sensitive data that you cannot show us, run it with dummy data on new file(s) created especially to find just one instance of the sequence), including the search expression you used to generate that Find Result.

[Alan Kilborn]

Some users may not be aware that you can also “keyboard around” with the arrow keys once the Find result window has input focus, and then when you are on a match line of interest, pressing Enter should take you to the source line for that match. Should be equivalent to double-clicking with the mouse.

[PeterJones]

@PeterJones said in Often nothing happens when double clicking on find in files results:

Did you realize it’s double-click

@Mario-Valle,
Sorry, I just re-read the title, and saw that you were double-clicking. That wasn’t clear from the main text.

But we still need more info to be able to help you.

[Mario Valle]

Yes, I double click on the line.
Yes, I know I can use arrows to navigate the results list, but the result does not change. On pushing Enter on the line, the editor does not open the corresponding file on the selected line.

I noticed that, if I collapse the section ‘Search “word”…’ the line that cannot be selected remains visible, like it is not part of the search results.

Here is an example. These are the results of a query:

The line 1032 is the one that cannot be selected. Here is the last one, but not always it is so.
Then collapsing the section:

leaves line 1032 visible.
I’ll try to setup a minimal example. Hope to succeed…
Thanks!
mario

[Mario Valle]

OK, found a minimal example. Searching the same word (with find in files) in the file containing line 1032, gives the same behavior. But if I cut the lines starting few lines after line 1032 the problem disappears.

Via a private channel I could send you the file and the detailed steps to reproduce the problem.

Thanks!
mario

[Mario Valle]

I shortened the file before the match and the problem remains.
But if I cut even few lines after the match the problem disappears.

[Mario Valle]

Here is the output of “Debug Info”:

Notepad++ v7.9 (32-bit)
Build time : Sep 22 2020 - 03:24:22
Path : C:\Program Files (x86)\Notepad++\notepad++.exe
Admin mode : OFF
Local Conf mode : OFF
OS Name : Windows 10 Enterprise (64-bit)
OS Version : 2004
OS Build : 19041.508
Current ANSI codepage : 1252
Plugins : ComparePlugin.dll DSpellCheck.dll HexEditor.dll HTMLTag_unicode.dll MarkdownViewerPlusPlus.dll mimeTools.dll NppConverter.dll NppExec.dll NppExport.dll NppFavorites.dll NppFTP.dll NPPJSONViewer.dll NppSaveAsAdmin.dll NppTextFX.dll XMLTools.dll _CustomizeToolbar.dll

To reproduce:
Load the file
Open “Find in files”
Search for “stupiscono” in *.md
“Normal” Search in all subfolders.

[Alan Kilborn]

@Mario-Valle

Maybe you’d better open an “issue” here:
https://github.com/notepad-plus-plus/notepad-plus-plus/issues

Where you can attach a file demonstrating the problem.

[Mario Valle]

OK, done. Issue #9009

[PeterJones]

@Mario-Valle ,

Given the file you attached to #9009, I could not replicate your results:

edit: that might mean it’s a 32bit issue; haven’t tried that… </edit>

[PeterJones]

@PeterJones said in Often nothing happens when double clicking on find in files results:

that might mean it’s a 32bit issue; haven’t tried that…

So I grabbed a fresh portable 7.9 32bit, and it behaved identically to my animation above: it properly opens the file and goes to the matching line, whether I have word-wrap on or not, and whether I’ve moved somewhere else in the file or not.

[Mario Valle]

Mystery. The only difference that I see is that your is 64 bits and mine 32 bits.
My original test was with the same file but with .md extension and filtering for *.md But the problem happens on my side also for .txt extension.
These are the only differences I see.
Seems a very fragile test, sorry. Seems changing very little and the problem disappears.
Anyway, thanks for your efforts
Best
mario

[PeterJones]

@Mario-Valle said in Often nothing happens when double clicking on find in files results:

The only difference that I see is that your is 64 bits and mine 32 bits.

Which is why I also tried with the fresh portable 32bit version, and found that it behaved the same as 64bit version for me. So it’s not bits that are causing the difference.

Have you rebooted recently? Sometimes, that magically makes such problems disappear. ;-)

[guy038]

Hi, @mario-valle, @peterjones, @alan-kilborn and All,

I think that I understood the problem !

The bug occurs whatever the type of search is run ( Find All in Current Document, Find All in All Opened Documents or Find All ) I could reproduce the problem with N++ v7.8.5, 32 bits and the last version v7.9.0, 32 bits

It does not depend of the search mode Normal or Regular expression nor of the Word Wrap feature

Briefly : When the search concerns an expression, in a line of more than 1,002 characters and that you process successive searches, let’s say, 3 times, for the same expression or even an other one, a double-click on this long line, in the Find Result panel, moves to the concerned line of the concerned file, ONLY for the FIRST of the searches done ! Any double-click on this long line, in the subsequent searches, displayed in the Find result panel, does NOT work at all !

To reproduce the issue :

• Download the bug.txt file of @mario-valle :

https://github.com/notepad-plus-plus/notepad-plus-plus/files/5378450/bug.txt

• Open this file with Notepad++

• First, deletes the end of the long line 4, which begins with Nelle nostre «Case dei Bambini», in order that the line contains exactly 1,002 characters ( not included line-break chars ! ). Personally, I ended this line with «bambini indipendenti» che 89012 to correctly see from the 998th to the 1,002th final character !

• Run a first search of the word indumenti, clicking on the Find All in Current Document

• Run a second search of the word spolverare, clicking again on the Find All in Current Document

• Run a third search of the word indumenti, always clicking on the Find All in Current Document

• In the Find result panel, right-click on the context menu and choose the Uncollapse All option

• You can easily verify that a double-click at any part of these 3 lines, correctly, selects the right word, in the bug.txt file

Note that the two words spolverare and indumenti occur only once, in line 4 of @mario-valle’s file !

• Then add just ONE character to the line 4 : I chose the digit 3 so the line ends with «bambini indipendenti» che 890123. Now, the line is 1,003 chars long, OK ! Redo all the process :

• First, clear the Find Result panel, using the Clear All option, from the context menu

• Run a first search of the word indumenti, clicking on the Find All in Current Document

• Run a second search of the word spolverare, clicking again on the Find All in Current Document

• Run a third search of the word indumenti, always clicking on the Find All in Current Document

• In the Find result panel, right-click on the context menu and choose the option Uncollapse All

• Now, double-click on each line of the Find result panel. It’s obvious that a double-click on the line, relative to the 1st search processed, works correctly. However, a double-click on the two other lines, relative to the 2nd and 3rd searches, produce nothing !?

---

Of course, I’m going to refer to this post in the GitHub issues 9009 and 8525 !

Best Regards,

guy038