Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Next/Prev Search Results don't act on current Find-result window #9080

Open
sasumner opened this issue Oct 30, 2020 · 5 comments
Open

Next/Prev Search Results don't act on current Find-result window #9080

sasumner opened this issue Oct 30, 2020 · 5 comments
Labels

Comments

@sasumner
Copy link
Contributor

sasumner commented Oct 30, 2020

Description of the Issue

The menu commands Next Search Result and Previous Search Result act only on the original Find result window, not the active Find result window.

Steps to Reproduce the Issue

  1. Create and save a file with the following text:
Jack and Jill
Went up the hill
To fetch a pail of water
Jack fell down
And broke his crown,
And Jill came tumbling after.

Up Jack got
And home did trot,
As fast as he could caper;
And went to bed
And plastered his head
With vinegar and brown paper.

When Jill came in
How she did grin
To see Jack's paper plaster;
Mother vexed
Did whip her next
For causing Jack's disaster.
  1. Do a simple Find All in Current Document search for the text Jack
  2. Observe:
    image
  3. Right-click in the client area of the Find result window and choose Find in these found results...
  4. Untick all checkboxes and search for Jill
  5. Observe:
    image
  6. Click in the main editor window
  7. Use the menu commands Next Search Result and Previous Search Result (or F4 / Shift+F4, respectively), several times, randomly.

Actual Behavior

Commands in step 8 moved between results of the first search, finding Jack

Expected Behavior

Commands in step 8 should move between results of the second search for Jill, since it is the Find result window that is active and currently showing to the user.

Debug Information

Notepad++ v7.9.1 (64-bit)
Build time : Oct 27 2020 - 05:04:37
Path : C:\..........\npp.7.9.1.portable.x64\notepad++.exe
Admin mode : OFF
Local Conf mode : ON
OS Name : Windows 10 Enterprise (64-bit)
OS Version : 1809
OS Build : 17763.1457
Current ANSI codepage : 1252
Plugins : mimeTools.dll NppConverter.dll NppExport.dll

@clachen
Copy link

clachen commented Nov 22, 2020

Here is a potential fix to the issue, which as far as I could discern did not cause any other bugs.
It was done by reassigning already existent information to the _pFinder pointer for search next result to access.
#9191

@donho
Copy link
Member

donho commented Nov 27, 2020

It's not really a bug to me.
The fact of word(s) searched in "Find in Search result" dialog excluded in the searching words list doesn't surprise me.

Even you force to consider it as bug, it's a minor one - user can always pick the word(s) he/she wants then search again.

@sasumner
Copy link
Contributor Author

@donho I agree it is a minor bug, because most users don't even know that you can "find in finder", but to me it seems reasonable that the shortcuts should move in the currently active Finder ...OR... when used and the main finder is not active, it should switch to the main finder before moving amongst the results. Otherwise user is confused as to what is happening.

@sasumner
Copy link
Contributor Author

@donho said:

It's not really a bug to me.

Again, knowing that would have been more helpful at "issue time" than at "PR time".
At "issue time" the only effort expended is that which it takes to write up the issue.
By "PR time" someone has put coding/building/testing/debugging effort in, which can be significant.

@donho
Copy link
Member

donho commented Nov 29, 2020

@sasumner
I see your point. Let's keep it opened so we are aware of this issue.
OTOH, it won't be "fixed", since it's not a bug to me.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants