A bug report which needs someone to repeat
-
This bug is closely related to the document list pane and files having dual views. I hope someone would like to repeat it to make the bug report confirmed.
First I show 1 snapshot that is seemingly wrong!
![f0f8bd94-b0a9-43d5-8b63-2ca3c61e44c8-Screenshot (573).png]Lines 49 and 52 are the same.
It opened 7 same files with different names. Files 4 to file 7 have dual views. One view pane is hidden, another is maximized.
Start to select strings “entity sync_fifo is” to find.
Click “Find All in All Opend Documents”.
Now bug will show.
Click same fine name 5 with a different view pane.
When 7 files are opened and 4 of them have 2 views, the bug appears very quickly if you try to click a file in the document list pane or the search result pane in random order. After the bug is shown if you click the left button on the content view pane, more random errors will happen and the Notepad++ enters an unstable condition. If the search result pane is closed, it returns to normal status.
I tried to use 2 files and one of them has 2 views to make things simpler to repeat, the bug does not appear. If 2 files and both have 2 views, the bug happens, but not very often. I suggest anyone who tries to confirm the bug, please open 7 files and 4 of them have 2 views.
-
I would like to provide more information to help the code designers debug the situation.
- Version is 8.1.5 (32-bit).
2 The bug happens when 2 or more files are opened and many of them have 2 view panes; the more files are opened, the more files have 2 view panes, the easier the bug appears, and the bug only appears under the condition that one file pane is hidden and another is maximized.
- The Notepad++ is stable when both file panes are visible. So when I want to use the search result pane, I manually change the horizontal pane separation bar to let both file panes visible.
The current viewing design rules under the document list pane are problematic. File content is visible only when its view pane is visible that often leads users to edit wrong files: when they click the document list pane to try to switch to edit a different file they will certainly edit a wrong file if the clicked file’s view pane is hidden. If they immediately start editing, they edit a wrong file that is the visible file, not the clicked file.
My suggestion:
The best way to eliminate the bug is to change the file appearance rules: if one file view pane is maximized and another is hidden, any file, regardless of whether it belongs to the upper pane or lower pane, will be shown in the maximized pane with the horizontal pane separation bar properly adjusted.
-
@W-TX said in A bug report which needs someone to repeat:
help the code designers debug the situation.
Do you know what would really help the code designers debug the situation? If you were to read the FAQ you’ve been directed to multiple times ¹ ² ³, and follow the instructions there, so that the designers actually see your bug report, instead of stubbornly refusing to report bugs in the correct location. Until you actually follow through and make an official report to the designers, instead of just telling us fellow users, nothing will ever happen with your “requests”.
-
I think it is OK for OP to initiate the discussion here, because I’d like to see someone reproduce it before an actual bug report is logged. OP had a seemingly-related issue RECENTLY, which I tried to recreate and I decided there really wasn’t a bug there.
-
You make a good point.
I am just afraid that this particular user is suffering under the false assumption that reporting a bug here is the correct procedure for making an official bug report. As long as it’s always made sufficiently obvious in any such discussion that in the end, we cannot change Notepad++ code here. if we can confirm that there’s a bug, the OP will have to make an official feature request
-
@PeterJones said in A bug report which needs someone to repeat:
I am just afraid that this particular user is suffering under the false assumption that reporting a bug here is the correct procedure for making an official bug report
Ha, well, if OP checks back in a while and complains about no action, he could always be “set straight” at that point. :-)
Of course, even if it is a real bug and OP puts in a real bug report, he could still have that same (no action) complaint, after some time has elapsed. :-)
-
Indeed.
But, as with you and the recent request, I cannot replicate the problem that @W-TX described in this post. I created twelve files, all which contain the word “find” on one line and another line of text either before or after, then did find-in-all-opened-files on
find. The prime numbered files were only in secondary (two,three,five,seven,eleven); the square-numbered files were in both views (one,four,nine); and the other files were only on the primary view (six,ten). I can double-click on the results in any order, whether I’ve got the view collapsed (using the < or > arrow on the dividing line) to just primary, or just secondary, and it will do exactly what I expect: if the result file is active in the visible view, that file will be brought to the front; otherwise it won’t; but I don’t get any behavior that I would count as “instability” or see any “random errors” (whatever that means).So until @W-TX can come up with a repeatable series of steps that others can reproduce, I agree, no bug has been confirmed so it’s not yet time for an official bug report.
-
- I appreciate your efforts to try to repeat my suggested steps very much. Repeating the bug is the most important thing to do. I will ignore all other unrelated opinions.
.2. One must first maximize one pane and hide another to start to do a search.
-
I suggest using the lower pane first to do the search, that is, select a string at the maximized lower pane with the upper pane hidden. Please search for a string, not a word, the most important thing is to repeat the bug, I don’t know if there is a difference. But please follows my suggested steps to repeat the bug. If there is another person who can repeat the bug, it says the bug exists, no matter how many other operations you do and fail to reproduce the bug.
-
After the search result pane is open, alternately click an item in the document list pane and search result pane, prefer not to touch the file view pane. If you click the files that belong to the same pane, everything is good, so I suggest you click files that do not belong to the current pane repeatedly.
-
I am waiting for other people to repeat the procedure to reproduce the bug.
-
In my case I have almost 40 files opened. So after the new version is updated, it just takes me a few minutes to find the bug.
The bug exists in the earlier version. But this new version seems more unstable so one time I thought to reinstall the early version.
My title is “Bug report”, everyone knows it never is an official report, but I hope that will attract more volunteers to join the efforts to prove the bug and finally get the bug removed by code designers. I have done my best to reproduce the environment to let other people repeat the bug.
,
-
@W-TX
I assume you open files from file-1a to file-7a, and appendix -a represents the file has view pane at the upper pane, and each of file-4a to file-7a has 2 views and the files belonging to the lower pane are marked as file-4b to file-7b.The most preferable key clicking string is the search result pane for -a file, the document list pane for -b file, and so on.
-
@W-TX ,
One must first maximize one pane and hide another to start to do a search.
What part of “whether I’ve got the view collapsed (using the < or > arrow on the dividing line) to just primary, or just secondary” did you not understand? The “collapsed” is the correct terminology which aligns with your “maximize”. I even told you what I clicked to do that, which should have been enough to overcome any language barrier.
Please search for a string, not a word
A word is a string. The search engine makes no distinction.
, alternately click an item in the document list pane and search result pane, prefer not to touch the file view pane
I never touched the file view pane during that experiment.
I am waiting for other people to repeat the procedure to reproduce the bug.
You will likely be waiting a long time, unless you can provide a simpler way of reproducing the bug.
finally get the bug removed by code designers
If there really is a bug, and others could confirm it: even if you reported the bug 1000000 in this forum, it would do no good, and would not cause the code designers – who have not been told of the bug – to do anything.
I will ignore all other unrelated opinions.
I am unable to help you any further, because you ignore what I say or what I say is incomprehensible to you. Maybe someone else will find some other way to helo you. Good luck.
