- StringDlg (Rename Current Tab, ...)
- UDL Styler
- UDL in undock state
- UDL allow tab switching between main dialog and subdialogs
- make controls spacing and size consistent
ref #14959Close#15024
- Run
- Run a Macro Multiple Times...
- Shortcut
- code enhancement
- add override in shortcut.h
- modify switches in WM_COMMAND
- optimize dark mode for shortcut
- avoid potential multiple subclassing for Run dialog
ref #14959Close#15017
Currently while flush file buffers action fails at not critical end session, a error message dialog display the problem.
It raises the problem of some external process interfering with the Notepad++ file saving (via NppSaveAsAdmin plugin).
This commit logs this error at critical end session, so if NUL characters content issue happens to the users again, we can try to know what was happening, plus users' plugin list.
Ref: https://github.com/notepad-plus-plus/notepad-plus-plus/issues/14990#issuecomment-2054242025Close#15003
- fix linux build on include upper/lowercase issue ../src/dpiManagerV2.cpp:20:10: fatal error: CommCtrl.h: No such file or directory
- avoid clang warning: 5>..\src\WinControls\Grid\BabyGrid.cpp(677,7): warning : unused variable 'rectwhole' [-Wunused-variable]
- avoid ../src/NppCommands.cpp:1790:24: warning: conversion from ‘int’ to ‘UCHAR’ {aka ‘unsigned char’} may change value [-Wconversion]
Close#15001
To be able to work with 2GB+ files, we have to use the Scintilla SC_DOCUMENTOPTION_TEXT_LARGE flag.
Until now, this flag was only used if a file > 2GB was to be loaded. For files smaller than 2GB or newly created empty ones, it was not used. This left the room for a Notepad++ crash situation because of the user has been left the possibility to cross this threshold (e.g. by pasting a data which in sum with the already existing ones in the Notepad++ filebuffer exceeds that 2GB...)
So one has two options: either a complex monitoring of the Notepad++ filebuffers size and reloading these with that large-flag when reaching the 2GB or simply using that large-flag as the default one from the start (which is what this patch does...).
Fix#14981, close#14982
- avoid upper/lowercase issue for #include <windowsx.h>
- casts to avoid warning: conversion from ‘int’ to ‘UCHAR’ {aka ‘unsigned char’} may change value [-Wconversion]
- cast to avoid warning: conversion from ‘int’ to ‘BYTE’ {aka ‘unsigned char’} may change value [-Wconversion]
- avoid warning : delete called on non-final 'FileDialogEventHandler' that has virtual functions but non-virtual destructor [-Wdelete-non-abstract-non-virtual-dtor]
- avoid warning : warning: extra ';' [-Wpedantic] in BabyGrid.cpp
Close#14950
Previously there was the 4096 MB max limit, so when e.g. user set this 4GB threshold and then tried to open any 2GB+ file, the Scintilla CellBuffer::Allocate method throwed a std::runtime_error because currently the Notepad++ does not use the SC_DOCUMENTOPTION_TEXT_LARGE in such a case.
The function "addHotSpot" can become very slow when the screen contains certain sequences of characters that look like URLs but are not valid, due to a form of backtracking. This change eliminates the possibility of backtracking.
This commit does two things:
First, it tightens the requirements for “looks like a URL” by checking the scheme earlier in the process. That is necessary to keep the next step from skipping valid URLs in reasonable contexts.
Second, once the beginning of a potential URL passes the tighter initial scanning and the end of the URL is found, we “commit” to that portion of the line. If the potential URL fails InternetCrackUrl validation, we restart scanning from the end of of the string that looked like a URL but wasn’t, rather than from just after the scheme.
Fix#13916, close#14900
The crash occurs because the thread terminates the task prematurely due to PostMessage’s nature. As a result, FileManager::backupCurrentBuffer() is always executed by the main thread, leading to a deadlock ( due to "std::lock_guard<std::mutex> lock(backup_mutex);") on the 2nd main thread’s entry and causing the crash. Here the explanation:
"If lock is called by a thread that already owns the mutex, the behavior is undefined: for example, the program may deadlock."
ref: https://en.cppreference.com/w/cpp/thread/mutex/lock
Using SendMessage instead of PostMessage ensures that the thread executes the task from the beginning to the end and keeps the mutex until the entire operation is terminated. Therefore, the race condition is prevented by the mutex lock while the 2nd thread tries to access the same code/zone.
Fix#14906, close#14917
ozone10