Notepad++ v8.4.9 Release

donho

@Lycan-Thrope
I don’t quit follow you.
Could you create an issue on Github and ping me.

Lycan Thrope

@donho ,
I can, but I just want to make sure I have the correct procedure, since I screwed up the thing earlier, and to make sure I’ve got the real use case. In this case, whether it has a space or not, this is what is happening. I can try finding a file with with a space but I tend to run on my names to avoid these kind of issues. :)

I’m not sure how to do the test that you asked for with the fix, so that’s my inexperience at issue. However, when I install the hack, in my machine and have opened 8.4.9 and minimize it so that when I double click on a .txt file, it will open the file in 8.4.9 instead of my default system installed version which is 8.4.8.
When I double click a .txt file, NPP 8.4.9 opens it with the orange coloring in the text area and states in the lower left corner that it is a JSON5 file. When I close 8.4.9, and then double click that same file, it opens in my default NPP 8.4.8 and opens it as a text file.
That basically describes the issue. I am able to use the hack, and it functions in 8.4.9, but it opens at least a .txt file as a JSON5 file type.
If someone else can find this behavior, I’d appreciate verification, to make sure I didn’t screw the procedure up, Earlier.

This is the Debug info for the file I just did this with, and then below that will be a screenshot showing the file open as I described. Below that will be a screenshot of the settings in the Registry Editor to show I did it right. :)

Notepad++ v8.4.9   (64-bit)
Build time : Jan 27 2023 - 03:11:16
Path : C:\Users\camilee\Documents\Development Tools Downloads\Notepad++ Versions\npp.8.4.9.portable.x64\notepad++.exe
Command Line : -notepadStyleCmdline -z "C:\WINDOWS\system32\NOTEPAD.EXE" C:\Users\camilee\Documents\foeagesgoodngproblemtext.txt
Admin mode : OFF
Local Conf mode : ON
Cloud Config : OFF
OS Name : Windows 10 Home (64-bit) 
OS Version : 22H2
OS Build : 19045.2486
Current ANSI codepage : 1252
Plugins : 
    mimeTools (2.9)
    NppConverter (4.5)
    NppExport (0.4)

Theo Niessink

FWIW, the minor Control-Tab regression seems to have been introduced in commit 662b54e28a (Add property sheet in VS project and clean project file), but I don’t (yet) know why though.

Alan Kilborn

“Lycan Thrope” 's discussion here moved to created issue: https://github.com/notepad-plus-plus/notepad-plus-plus/issues/13042

donho

@Lycan-Thrope said in Notepad++ v8.4.9 Release:

I’m not sure how to do the test that you asked for with the fix, so that’s my inexperience at issue. However, when I install the hack, in my machine and have opened 8.4.9 and minimize it so that when I double click on a .txt file, it will open the file in 8.4.9 instead of my default system installed version which is 8.4.8.
When I double click a .txt file, NPP 8.4.9 opens it with the orange coloring in the text area and states in the lower left corner that it is a JSON5 file. When I close 8.4.9, and then double click that same file, it opens in my default NPP 8.4.8 and opens it as a text file.

OK, I see the problem. This issue is happening because you still keep a previous version of Notepad++ on your machine (in C:\Program File\Notepad++\ ) but the launched instance is version v8.4.9 which you put in another folder.

The scenario of issue cause is: when you use context menu or Notepad replacement, both point to C:\Program File\Notepad++\notepad++.exe which is, let’s say version 8.4.8, without the support of JSON5, so a unknown language file is detected by C:\Program File\Notepad++\notepad++.exe (v8.4.8) as ENUM_UNKNOWN (number 86), then it passes number 86 as detected language to the launched instance C:\you-new-v849-folder\Notepad++\notepad++.exe, in which (v8.4.9) JSONS5 has been added as 86 and ENUM_UNKNOWN has been shifted to 87 - then this anomaly. happens.

To remedy this issue, updating C:\Program File\Notepad++\notepad++.exe from v8.4.8 to v8.4.9 is necessary, via installer or copy/paste notepad++.exe manually.

Lycan Thrope

@donho ,

I understand what you’re saying…but doesn’t that kind of negate the choice of using a portable version, so you can test stuff without the standard version being subject to any bugs that 8.4.9 may have that one doesn’t want to use in their production install? :)
Thanks for finding the issue, however, so quickly.

PeterJones

@Lycan-Thrope said in Notepad++ v8.4.9 Release:

@donho ,

I understand what you’re saying…but doesn’t that kind of negate the choice of using a portable version, so you can test stuff without the standard version being subject to any bugs that 8.4.9 may have that one doesn’t want to use in their production install? :)
Thanks for finding the issue, however, so quickly.

The “notepad replacement” mode, just like automatic assocations, are focused on installed versions. So it was your trying to mix “notepad replacement” and portable, when you also had an installed version, that caused a weird confluence of events which shouldn’t normally happen.

If I’ve understood Don’s description correctly, your “notepad replacement” was pointing to the installed version (8.4.8), but you already had portable v8.4.9 open, so Windows tried to run the installed, which did the detection (picking 86), but once single-instance Notepad++ saw that there was already a Notepad++ open, so it passed the file and the 86 to the already-open Notepad++ (v8.4.9) in which instance 86 means JSON5, not “unknown”.

Lycan Thrope

@PeterJones ,
Yep, that’s the way it sounded like he was explaining it to me, also. I get it, I just thought it humourous that we find what we think is a supposed “bug” in a new version and to get rid of it, we need to update to it. :) <-Notice smiley. :)

Theo Niessink

I think I’ve found a solution for the Control-Tab regression, so I’ve opened a pull request (#13067).

Jupercio Juliano

I do have the same issue, running 64-bit version on Windows 10 Pro version 22H2 build 19045.2486

Alan Kilborn

@Jupercio-Juliano said in Notepad++ v8.4.9 Release:

I do have the same issue

There’s like 31 postings in this thread…can you narrow it down to which topic you have the same issue as?

Theo Niessink

FWIW, plugins also look different in v8.4.9 when compared to v8.4.8. I guess this is also because v8.4.9 is a Windows Vista rather than a Windows XP executable now. Anyway, I think this is unlikely to cause any serious issues, so it’s probably fine.

wallobit

@donho Same problem in version 8.4.9 whenever there is a space in the path or file name. Without spaces in the file or path name it works. Version 8.4.8 or earlier is not affected. -notepadStyleCmdline -z no longer seems to interpret the complete file path and file name as a whole.

Alan Kilborn

@wallobit said in Notepad++ v8.4.9 Release:

-notepadStyleCmdline -z no longer seems to interpret the complete file path and file name as a whole.

Fixed, and fix will be in 8.5.

Register Noname

There is display bug on NPP, related to UTF-8 graphical symbols.
Here example of the text:
🞂 ◷ ◴ ◵ ◶ - clock
◷ ◴ ◵ ◶ - clock
This is how it looks in NPP

The bug is not limited to above symbols, there are quite a few that have similar issue.
Somehow putting that specific triangle symbol in the beginning of line suddenly makes all subsequent symbols also appear correctly.

PeterJones

@Register-Noname said in Notepad++ v8.4.9 Release:

🞂 ◷ ◴ ◵ ◶ - clock
◷ ◴ ◵ ◶ - clock

It appears that you want DirectWrite enabled; see Settings > Preferences > MISC. As the Preferences dialog says, turning it on “may improve rendering special characters”.

I confirmed in v8.4.9 with my settings, DirectWrite off will have display problems like you showed, whereas DirectWrite on will show all the characters correctly:

But the same has been true for many versions, not just v8.4.9, so this really should have been a separate topic, since it’s not specific to v8.4.9.

@donho: BTW, we frequently get questions here that are solved by DirectWrite being on. Is there a reason that we cannot have that setting enabled by default – that way, new users will just see Notepad++ work great with Unicode characters, rather than having to come complain about poor Unicode behavior and then be told that they need to change a setting. Let me know if you want me to create an issue.

Register Noname

@PeterJones I agree this was true for very long time. Sorry I’m new here didn’t want go with opening tickets right away :)
DirectWrite (whatever it is) indeed helped. Thank you!
I also agree that this setting should be enabled by default if the ‘standard behavior’ cannot be fixed.

guy038

Hello, @register-noname, @peterjones and All,

I did some tests and, indeed, the use of DirectWrite insrease rendering of characters !

I verified that, if the DirectWrite option is not checked, the four Unicode characters, provided by @register-noname, are properly displayed ONLY IF the current line contains a character with codepoint over the BMP, so with codepoint above FFFF !

Compare these two screen-shoots below :

0ad5f019-5ff1-43e3-b503-c49e8f04398d-Without_DirectWrite.png

WITHOUT Direct Write

And :

27f5dc38-0abb-47d7-b442-6aa2235cb64f-With_DirectWrite.png

WITH Direct Write

Note, particularly, the differences in lines 1 , 2 , 15 and 16 ;-))

Best Regards,

guy038

makuhlmann

Hi there, found a regression: the software does not launch anymore on Windows Vista and Windows Server 2008 systems (NT 6.0). The application quits with the error message

“The procedure entry point CoGetApartmentType could not be located in the dynamic link library ole32.dll.”

This issue seems to be present since 8.4.7 already, 8.4.6 is the last version that launches fine.

Alan Kilborn

@makuhlmann

This was noted HERE as well.
Perhaps the SUPPORTED_SYSTEM.md file is in need of updating.