Updated according to 924e4b2, 2b345c8, f637901, 2b713fb and 5a95153 commits. Hope nothing missed.
Close#8272
Btw, ``<replace-in-files-confirm-filetype value="For file type :"/>`` is that file type means like ``txt`` or ``type this``?
1. Add file extension automatically while changing file type via combobox in new style dialog.
2. Add file extension automatically for session files and workspace files while saving in new style dialog.
Fix#4876, close#8311, close#8312
Fix Mouse remains in clicked state after resizing docked windows:
The reason for the effect is the mouse hook procedure, which seems to be quite obsolete in contemporary systems: it catches the mouse messages and posts them a second time to the same window. I assume, that was ment to speed up the shifting of the splitters on "prehistoric systems" (That's what you call every system not supporting transparent windows). I see no regression without this hook.
What happens is, the hook catches the WM_LBUTTONUP message and posts it to DockingSplitter::runProc. Here, the hook is released and ReleaseCapture() is called. All fine.
But Windows fails to update its internal key state, when the WM_LBUTTONUP comes as an posted-by-a-hook message. So, if you call GetKeyState(VK_LBUTTON) after ReleaseCapture() in the original code, then it is still in a pressed state. Which confuses the Document Map later.
Fix#8285, close#8286
This PR fixes the following effects:
1. Document map overlay remains visible after minimize to tray.
2. Document map overlay is left behind on current monitor after moving Npp with Windows+Shift+Arrow to another monitor.
3. Document map overlay escapes to another monitor without Npp, when Windows+Shift+Arrow is pressed while the input focus is at the document map.
Fix#1317, close#8280
The current bug: the unconnected network or USB drive while loading a file from it is not detected. As a result Notepad++ opens an empty or uncomplete document.
This commit fix it by not opening anything and showing error box, if file reading fails.
Fix#3381, close#8267
The full story, debated before, is that regular expression searching in a backward direction from the caret position causes matches that the user does not expect. The best thing that was decided to do (group decision) is to fully disable upward searching.
Fix#3640, close#8269
