v8.7 Search Results Missing
-
Ctrl + shift + f not working (search is done but don’t pop up the windows with the results)
The keyboard shortcut Ctrl + Shift + F is not working. The search is executed, but the results window does not appear. I have updated to the latest version, but the problem persists.
–
moderator renamed and pinned Topic, since this is now the catch-all thread for the issue -
Presumably the same issue mentioned here and here.
As was asked (but never answered) in the other two discussions, @xomx will want to know if you are using one monitor, or more than one? If just one, is it “high DPI” or not? And if multi-monitors, are the monitors all the same DPI density, or is there a mix of DPI and/or screen resolutions involved?
-
@PeterJones It was working before, I just downgraded to several versions, and is not working anymore,
-
@PeterJones I was using 2 monitors then I disconnected it but the issue is the same.
-
@PeterJones Hi, I have figured out how to fix it.
go to C:\Users<YourUsername>\AppData\Roaming\Notepad++
Rename config.xml to config_backup.xml and restart Notepad++.And that did the trick!
-
Good job on figuring out a solution. I was about to explain that solution – or, actually, a more targeted version, as hinted at in this post, where I would have had you delete just that portion of the
config.xml
rather than the whole file), because deleting (renaming) the whole file also eliminates all your Settings > Preferences choices, so don’t do that if you’ve customized Notepad++ preferences.If you’ve still got your
config_backup.xml
, sharing that same section might help @xomx see what state the config file had gotten into (because there’s supposed to be fixes in Notepad++ v8.7 that prevent it from getting into that state… but maybe the multi-monitor setup confused the protection, allowing the config file to get into the messed-up state)update: BTW: this reset procedure was described in our FAQ more than a year ago.
-
@PeterJones Oh, I see, thank you for letting me know.
-
@Jairo-Florez said in Ctrl + shift + f not working (search is done but don't pop up the windows with the results):
Hi, I have figured out how to fix it.
go to C:\Users<YourUsername>\AppData\Roaming\Notepad++
Rename config.xml to config_backup.xml and restart Notepad++.And that did the trick!
@Jairo-Florez
Could you append here the content of your problematicconfig_backup.xml
(& also the current okconfig.xml
just for comparison)?
(just paste it to a reply here, select it and mark as the code via the</>
format toolbar icon in this forum; or post a link for downloading) -
@xomx and all,
I have updated the Cannot find my panel FAQ to have debug/fix instructions for v8.7 Search Results panel issues – it says to reply to this topic, so hopefully we can corral all the v8.7 Search Results discussions into this one location.
-
-
-
-
-
I am also seeing the problem with the Search results window being completely collapsed against the bottom of the window, and not accessible to resize. My version is NPP V8.7.1 64-bit, running Windows 10 Pro 22H2 build 19045.5131.
In my case the first instantiation of NPP opens correctly, and the Search results docked window opens correctly on the initial search. On subsequent instantiations of NPP, the Search Results window frequently does not appear. I can sometimes close my second instance, resize the search results window on the first instance, and get the window to appear in the second instance on the next launch. Sometimes this takes four or five launches to make it work. Third and subsequent instances have the same issue. (I frequently have three or four projects with 12 files each open in different NPP instances.)
Once the Search results window appears in any instance it works reliably for the remainder of that session. The problem is always with the first search after launch of instances 2 thru N. Once the Search results window is unreachable it never corrects itself.
It would be helpful to assign the docked window a hardcoded minimum size to prevent this dance. My first instance has been 100% reliable opening the Search results window, and subsequent instances are less than 10% reliable.
-
Thanks, with your info provided I am able to reproduce the problem now, this is how it then looks:
Exactly how some users reported that “cropping”, e.g.:
https://community.notepad-plus-plus.org/topic/26154/v8-7-status-bar-appears-cropped -
@John-Berting
I spoke too soon - I was going to debug the issue but I am not able to reproduce it anymore! Weird.Could you please paste here content (an then select that and format as the code here by the forum
</>
) of your N++ config.xml file located in your%APPDATA%\Notepad++\
folder (probably theC:\Users\[userlogin]\AppData\Roaming\Notepad++\config.xml
)?Or at least its “DockingManager” part:
<GUIConfig name="DockingManager" leftWidth="200" rightWidth="200" topHeight="200" bottomHeight="200"> <PluginDlg pluginName="Notepad++::InternalFunction" id="0" curr="3" prev="4" isVisible="no" /> <ActiveTabs cont="0" activeTab="-1" /> <ActiveTabs cont="1" activeTab="-1" /> <ActiveTabs cont="2" activeTab="-1" /> <ActiveTabs cont="3" activeTab="-1" /> </GUIConfig>
-
Finding a 100% reliable STR took me this time!
Finding a problem-trigger (actually one of my own PRs, ugh), was then easy.Current workaround - just close all the N++ instances (2nd, 3rd, etc…) with that panel problem visible, restore the 1st N++ instance from the minimized state and everything will be ok.
No fix yet - no time.
STR:
- Use any N++ v8.6.9+.
- There is no need to open any file in N++ in the following steps, but you can.
- Set multi-instance mode and close N++:
- Launch 1st instance of N++.
- Minimize it to the task-bar (IMPORTANT step!).
- Launch 2nd instance of N++, go to the menu > Search > Find > click “Find All in Current Document” button
- Look for the usual Search results panel:
- In this faulty state, you can now also try other panels (e.g. FaW) and see the same problem.
The immediate “culprit” is this v8.6.9 commit:
https://github.com/notepad-plus-plus/notepad-plus-plus/commit/8beda66cb8c77361216a43075e9be44ca32edbecIt is the very same commit that solves the previous “lost” of the panels by the users (when they minimized them inadvertently to zero width or height). I haven’t had time to look into a solution yet, but maybe it is a bug elsewhere that’s just become visible by this PR (and I am very curious at how simply minimizing another app instance can affect internal state of another app instance in such a drastic way, I hope I did not bump into another similar MS Windows bug like this … ).