Every new version shows the changes whens started first.
The file is located in the installation directory and is called change.log.
Concerning your issue - you can open an issue here.
I have problem with Windows 10 (64). When you run the NP ++ (x86 version) as an administrator, drag-drop file in window, does not work.
I assume that the access rights from source to destination are different.
E.g. when starting explorer with a normal user account and you want to drag
something into an application with evaluated rights than it get rejected
as otherwise you would cancel the whole permission concept.
Artur Harison last edited by Artur Harison
Some files are automatically defined as Mackintosh instead of the Windows-1251.
The problem occurs only when using the Cyrillic alphabet.
I’m a little bit confused by the video and the new text.
Video shows the previous question about privileges
whereas the new text indicates an encoding issue.
So I assume you do have two different issue.
Concerning the video let me try to explain what happens (or what doesn’t happen)
With introduction of UAC Microsoft changed their security concept and allowed
that different process with different privilege levels run on the desktop. This means,
that if you logon as a normal user explorer.exe gets started with the security token
of this normal user. When you start npp as administrator this process gets elevated rights,
meaning different security token.
The desktop where your file is located belongs to the explorer.exe process - if you drag this file
(as normal user) into npp (which run elevated) the security tokens don’t match and therefore it gets
rejected. You can only open the file if you use the file dialog menu from npp or when starting another
instance from explorer as administrator and dragging the file from it.
If you want to get more details about how exactly this works I would recommend searching the web for
- User account control (UAC)
- Mandatory Integrity Control (MIC) and
- User Interface Privilege Isolation (UIPI)
About the encoding - yes this can happen - there is no guarantee that npp finds the “correct” codec.
I tried to explain this already here.
Thanks for clarifying.
I just turn off ‘auto encoding character’ option.
Tom Arn last edited by
File with german umlaute not working
I created a text file with the Windows Notepad which contains german umlaute (e.g. ä ö ü=0x4e 0xf6 0xfc) and saved it with ANSI encoding. When I open this file with Notepad++ v7.3.1 the file encoding is shown as Windows-1255 and the umlaute are rubbish.
The same even happens if I create a new file with ANSI encoding in Notepad++ and enter some umlaute.
When I save and reload from disk, the encoding changes to Windows-1255 and the umlaute are rubbish.
gerdb42 last edited by
Try disabling “Autodetect character encoding” in Preferences->MISC. It sometimes produces odd results.
Strange behavior when copying the search results.
Context menu and Ctrl + C .
Problem of copying (video)
cmeriaux last edited by
@Artur-Hareson This is the expected behavior.