(Document list + Find + Multiple files + at least 1 file in dual show) bug:

[W TX]

Here are 4 steps when the error happens:

Document list is opened with a file content show at edit area and at least one file having 2 views;

1. Do a search with Ctrl+F and click “Find All in All Opened Documents” button;
2. Click mouse left button at one line of the search area to show a selected file search position;
3. Click mouse left button at file content area to try to edit the file;
   the contents are unstable, showing mixed content of the search line with contents of an unexpected file, or it immediately jumps back to original file with mixed contents.
   My current action is not to use search area content!

[Alan Kilborn]

@W-TX

The additional information provides nothing additional that I can see – it is still too vague for anyone else to do anything with. Can you post some screenshots to go along with your reproduction steps? The temptation would be to only post a screenshot of the end result (the messed up part), and that would be fine as a first step, but better would be your progression – and then someone could attempt to reproduce the same thing.

[W TX]

@W-TX said in (Document list + Find + Multiple files + at least 1 file in dual show) bug::

Here are 4 steps when the error happens:
Document list is opened with a file content show at edit area and at least one file having 2 views;

Do a search with Ctrl+F and click “Find All in All Opened Documents” button;
Click mouse left button at one line of the search area to show a selected file search position;
Click mouse left button at file content area to try to edit the file;
the contents are unstable, showing mixed content of the search line with contents of an unexpected file, or it immediately jumps back to original file with mixed contents.
My current action is not to use search area content!

After your post, I go deep into the bug and found in what condition the bug can be regenerated, I miss some important steps.

1. Document list pane is opened.
2. At least one file has 2 views, do not show two panes of file contents.
3. All files belong to the upper pane, except some that are at the lower pane which is shown fully with the upper pane hidden.
4. Do a search with Ctrl+F and click “Find All in All Opened Documents” button with the low pane fully viewable.
5. Click the mouse left button at one line of the search area to show a selected file search position whose file is in the upper hidden pane;
6. The selected file which belongs to the hidden upper pane is fully shown in the low pane correctly. A user thought that the selected file can be edited, but it does not.
7. Click the mouse left button in the file content pane to try to edit the file, the content immediately returns to the low pane file, not the shown file.
   The bug is: when clicking a search result area, if the file belongs to the hidden pane, it correctly shows its content in the shown pane but does not switch pane internal setting, the shown pane should correctly switch to its belonging pane, and not remain at shown pane.
   Actually, the problem bug is hidden at a needed design improvement: when a document list pane is open, there are 2 views for some files. If a user shows only one pane, hidden one pane and maximizing another pane, either low pane or upper pane, click any file in document list the shown pane should properly change its full pane setting: if the current full pane is low pane which is in maximized status, when a user clicks a file at document list that belongs to the upper pane, then the fully shown pane setting should go to upper pane without user moving horizontal pane bar to show the upper pane.
   The design is suggested to do following improvement: when there are 2 views for some documents, one view pane is hidden, another is in maximized mode, clicking any document in the document list, view pane should automatically change the internal setting to properly show the clicked document in the maximized mode without user moving horizontal pane bar. If two views are visible, the current method is excellent.

[Neil Schipper]

@W-TX It’s super easy to provide images: get the editor into a state that is relevant to your problem, hit Alt-PrintScreen, then, in the entry form for a post to this forum, hit Ctrl-v to paste.

This will save you and your readers much time, and avoid confusion.

[W TX]

@Alan-Kilborn
Here are snapshots that should give one a very clear picture of what improvement should be made and where the bug is located. I list one suggested improvement post each time so we can focus on only a small step and you know what I describe.

All files are the same for show example purposes.

Problem 1: there are many files having double views, one cannot recognize which one is at the upper pane or low pane.

Suggested Improvement:

1. All files belonging to the upper pane or low pane should have different color icons.
2. All files belonging to the upper pane should be listed at the upper part of the document list pane, and all files belonging to the low pane should be listed at the low part of the document list pane.
3. There should be a line separate the upper pane file names from low pane file names.

[Alan Kilborn]

@W-TX

Sorry but I still have no idea what you are talking about. Perhaps someone else will jump in and can help you. I’m out.

[Neil Schipper]

@W-TX said in (Document list + Find + Multiple files + at least 1 file in dual show) bug::

I don’t know if I can be of much help but in regard to:

There should be a line separate the upper pane file names from low pane file names.

There may be benefits to your use of “Document List” that I’m not aware of, but you may have a better experience if (in Pref-Gen) you turn this panel off, and turn on (=unhide) Tab Bar, and set it to Vertical. This way, in dual pane editing, there will be a visual separation between the two file groups. If a file is open in both panes, it will easier to tell which tab goes with which pane.

Some hints about expressing things (in this context):

• instead of “Click mouse left button”, say “click”
• instead of “search area”, say “search results pane” or “search results window”
• instead of “search position”, say “match” or “hit”

Finally, in your first post you wrote

the contents are unstable, showing mixed content of the search line with contents of an unexpected file

If a “find in files” operation results in bad behavior, this is where screen shots are very useful, and be clear about what happened, for example “in the results window, I clicked the match for Line 5 of 1-Fifo but it took me to Line 8 of 2-Fifo”

[W TX]

@Neil-Schipper
Thank you for your answer, especially helping me pointing to my spelling error.

I currently now open about 40 files to simultaneously edit them. So using the Tab Bar method is not an option.

This bug is closely related to the document list pane and files having dual views.

The above two panes show where the bug starts: a file in the document list pane has 2 views.

Move horizontal bar between the upper pane and the lower pane upperward to hidden the upper pane and maximize the lower pane. Click Ctrl+F keys to pop the “find window”, click the button “Find All in All Opend Documents” and get the following search result.

It has no problem, everything is normal.

It has a problem! I clicked the search result for 1-FIFO-Example, but it shows 7-FIFO-Example as shown in the document list pane. It enters the bug.

I clicked the last 7-FIFO-Example in the document list pane; it returns normally.

I further clicked the first search result for 1-FIFO-Example, it suddenly shows 2 same lines: “entity sync_fifo is”. And I found the situation becomes unstable, so I stopped immediately to avoid any damage to the edited files.

There is my analysis of the conditions under which the bug appears.

1. The document list pane is opened with at least one file having 2 views.
2. Move the horizontal bar between the upper pane and lower pane to hide the upper pane and maximize the lower pane.
3. Do a search with multiple files selection.
4. Click the mouse left bottom at the search results pane to show a selected file search position that belongs to the upper pane.
5. The bug happens.
6. If the mouse left bottom at the file content pane is clicked to try to edit the file, a bug appears and the editor enters an unstable condition.

The description of the bug conditions is slightly different from the copied snapshots, the reason is when it is entered into described conditions status is always unstable and has many different bad and unpredictable behaviors.

Here is my observation of why the error happens.

The bug is closely related to 2 view pane scheme. When one view pane is maximized and another pane is hidden and do a search for multi-files.

After the search, the maximized pane is the main pane. After clicking the search results pane for a file with the same pane, there is no error; when clicking the search results pane for a file with a different pane, the error appears.

The handling of the document list pane should be improved while the same bug would be corrected and disappear.
The 2 view mechanism is a very useful tool. When it is to compare one file with another file 2 views mechanism is necessary. But for most of the time, a Notepad++ user always prefers using one maximized pane and one hidden pane. He does not care about whether a currently edited file is in the upper pane or the lower pane. So the software designer should have such a design that when a file in the document list pane is clicked, it is always automatically shown in the maximized pane and the maximized pane setting is changed accordingly and belongs to the file. Currently, when a view pane is maximized and a file belonging to the hidden view pane is clicked, it shows nothing changed in the view pane because the hidden pane is hidden and the user has to manually move the separation bar to show the hidden file. The current design is not a good decision, it generates the bug I have showed and it also causes an uncomfortable edit environment.

[Alan Kilborn]

I attempted to reproduce your problem and I was “sort of” able to do it.

There is no concept of a “hidden” view. Just because you “hide” it by shrinking it to zero size doesn’t give it any special status.

What happens when you double click on a search result is that the correct file is activated in the primary view (the one that you seem to have “hidden”). This just happens to be the way it works with a cloned file–the double-click activates the owning file’s tab in the primary view and jumps the caret to the match. You’ll see this, if after activating the match you “unhide” the upper (primary) view and check to verify what file and line number it is at.

[Alan Kilborn]

Perhaps this could be a new feature request:

• If the file is not cloned, and the view the match is in is fully collapsed, uncollapse it (to a 50-50 split?) to show the tab of the source of the match

• If the file is cloned, and the primary view is collapsed, use the secondary view’s tab when going to the source line for the match (otherwise prefer showing the match in the primary view)

[W TX]

@Alan-Kilborn said in (Document list + Find + Multiple files + at least 1 file in dual show) bug::

There is no concept of a “hidden” view. Just because you “hide” it by shrinking it to zero size doesn’t give it any special status.

What I suggested is to give the mode of 2 view panes a special bit View_Mode in code design: 0: there is only one main pane; ‘1’: both panes are visible.

Now we don’ have to talk about the property: if a file has the primary view or the secondary view.
It is a new concept, making the dual-pane scheme much more user-friendly.

1. When starting, View_Mode = 0, showing only one pane.
2. When a user introduces a second view, the main pane is split into two panes, the top one and the bottom one, and View_Mode is set to 1. If a user shrinks any of the 2 panes, the View_Mode becomes 0.
3. Now new rules apply: regardless of where a file item is clicked, either is at the document list pane or the search result pane, if View_Mode = 0, the file content is shown in the main pane; if View_Mode = 1 the clicked file is displayed at one of the two-panes that is decided when it is opened.

The reason is users spend their most time in one window mode and if there is any need, they need to show 2 panes, especially for comparing.

It mimics the “Compare” function: when a comparison of 2 files is required, it automatically introduces 2 visible panes, the first selected one is at the top, the second selected file is at the button. After the comparison is finished it returns to the original status.

[Alan Kilborn]

@W-TX

I’d rather not tell the developers how to do their job, at that level. Plus, well, I don’t know, but I find your wording hard to read and follow.

[W TX]

@Alan-Kilborn said in (Document list + Find + Multiple files + at least 1 file in dual show) bug::

I attempted to reproduce your problem and I was “sort of” able to do it.

1. Could you please post the snapshots You repeated the bug, and describe how they are made, so more people can repeat the error and understand under what conditions the bug happens.

2. Could you please post the bug to the appropriate website to let NP++ developers know about the bug. I posted the bug here, hope someone can repeat the bug and report the bug upperward. As a heavy user of the NP++, spending almost 8 hours a day using the NP++, my duty is to report here any types of bugs and suggestions to make NP++ more user-friendly.

3. My improvement suggestion in 1 sentence:
   After a user collapses one pane of 2 visible content panes, there will be only one maximized window, showing any file a user most recently clicked, regardless of the position the new clicked file belongs to. Show 2 panes only when a user moves pane separation bar to let both panes visible,

[artie-finkelstein]

Alternate suggestion (somewhat alluded to by a previous response by Alan Kilborn):

Don’t move the vertical separator bar so that one of the views is fully obscured, leave at least one text line visible. The obscured pane is only hidden from the user, not from the editor. When a user makes the pane effectively invisible, what they are really doing is saying don’t show me the contents, so when the editor changes the contents (scrolls the file to display the match) the user can’t see what is going on.

This may not affect the purported bug, but it should at least make it easier to see what is going on. I do note that the Find All in All Opened Documents option will resize the document views to allow space for the Search results window and this may require appropriate resizing of all three panes.