While user tries to save a file which requires administrator privileges,
another instance in admin mode could be launched to save the file in
question.
Make it take generic_string instead of TCHAR*, since at most callsites
we already have a generic_string.
Improve error handling. Depending on where we are in the function when
we get an error, we need to free the memory, unlock the memory, or
close the clipboard.
Note that if SetClipboardData succeeds then we should not do anything
more to the memory.
Just copy the actual results, without the additional formatting with
line and file name. It respects the hierarchy in the results, i.e.
you can copy all results from a search operation, or from a specific
file, or just the lines you selected.
When writing the parameters as a XML file (when the application quits), a new
node was created but not destroyed (`InsertEndChild` makes a clone of the
given node).
When loading a file via `FileManager::loadFileData`, a fixed-length buffer
is filled via `fread`. Then, in some cases, a conversion is done with the help
of `Utf8_16_Read`. However, the method `Utf8_16_Read::convert` performs a call
to `strlen` on this buffer. This is obviously wrong: `\0` char should be
accepted (even if a bit strange) and the buffer is not zero-terminated.
The changes merely consist in adding an additional parameter `length` to
not have to guess the size of the buffer.
The method `FileManager::loadFileData` uses a stack-based buffer for reading
a file. However, due to the optimization used by `Utf8_16_Read` (`UnicodeConvertor`),
this buffer is not copied, but a pointer to this object is kept.
After `loadFileData`, this object is destroyed, but is used afterward
(via `UnicodeConvertor.getNewBuf`).
The non-default constructor of the class Buffer calls the inner method
`checkFileState()`, using the private variable `_currentStatus` to determine
whether some checks on the file attached to the buffer are required or not.
However this variable is properly initialized _after_.
The session snapshot feature runs in its own thread and access to
Scintilla etc is not thread-safe. As a *temporary* and *non-exhaustive*
fix we guard some long-running operations (undo, redo, replace, sort)
with a mutex to prevent data corruption.
