Control symbols now inserted on macro

  • Greetings,
    I’m using the next macro instruction to insert the tri-dot character ‘…’ in text

            <Macro name="CharTridot" Ctrl="yes" Alt="yes" Shift="no" Key="190">
                <Action type="1" message="2170" wParam="0" lParam="0" sParam="&#x2026;" />

    But, beginning from yesterday, after I’ve installed the new version of Npp (7.8.1, former version seems 7.7.1), except the tri-dot character, Npp also additionally insert a special character “EOT”.

    Is it a bug, or some new feature and now I must to change my macro instruction?


  • I can confirm the same behavior: in v7.7.1 64-bit, that macro worked as expected and just inserted the ellipsis. In v7.8.1 64-bit, that same macro inserts the ellipsis plus other character(s). I haven’t gotten the EOT character; but every time I unload and reload 7.8.1, running that macro gives different random extra characters. For example, one run, I got “…x82RSOH”; then I reloaded, and the macro now gives “…xCB1STX”.

    There was a Scintilla component change between Notepad++ v7.7.1 and v7.8, so that may have been the cause. It appears that there’s a string buffer overflow, and it’s reading data from memory not associated with the string in the macro.

    Since it looks like a bug (to me), I recommend following the FAQ for submitting a bug report.

  • There was some recent work on including more macro-recordable features which maybe introduced a string buffer issue.

  • @PeterJones Thanks for reproducing and confirming weird behavior.

  • I’ve created the topic on the issue, it is available here:

  • Hello, @oasisindesert and All,

    Why don’t you use the Microsoft Alt Numpad input method ? Refer below :

    For instance, as I’m French, my default ANSI Windows code-page is Windows-1252. Now, using the Edit > Control Panel feature, of N++, it’s easy to notice that the Horizontal Ellipsis character ( ) has the hexadecimal code 85, so the decimal value 133.

    Thus, to write this character, at any time, simply :

    • Press the Alt key ( at left of the Space key )

    • Press, successively keys 0, 1 , 3 and 3 on the numeric keypad, while keeping the Alt key pressed

    • As soon as the Alt key is released, a character will automatically be inserted, in your text, at cursor position ;-))

    It is very important to point out that the first key to press must be the 0 key !

    Indeed, if you just press, successively, on the three keys 1 , 3 and 3, a character is inserted, as well, but, this time, it represents the character, with same hexadecimal code, of the DOS OEM code page, which is the CP850 Latin-1 code page, in Western countries !

    The nice thing is that I could record a macro, with the same shortcut ( Ctrl + Alt + . ), by doing the following operations :

    • Click on Macro > Start recording

    • Hold down the Alt key

    • Press, successively, on keys 0, 1 , 3 and 3, of the numeric keypad

    • Release the Alt key

    • Click on Macro > Stop recording

    • Click on Macro > Save Currently Recorded macro

    • Enter “Tri-dot char” as macro’s name

    • Check, both, the CTRL and ALT boxes

    • Select the . item, in the drop-down list

    • Click on the OK button to valid all the changes

    • Preferably, stop and restart Notepad++, in order that this new macro is saved in the Shortcuts.xml file

    I obtained the macro, below, which seems strictly identical to yours !?

            <Macro name="Tri-Dot char" Ctrl="yes" Alt="yes" Shift="no" Key="190">
                <Action type="1" message="2170" wParam="0" lParam="0" sParam="&#x2026;" />

    However, I did not notice any problem, even when hitting , repeatedly, on the macro shortcut ;-)) For instance, I wrote a single line of 200 *ellipsis chars, about, , without any additional control character ! So, how did you record your own macro ?

    May be, it would be interesting to verify your “keyboard speed” In a DOS console window, type mode con rate=32 delay=0 and then, verify, with the command mode con that the values of repetition frequency and delay before repetition are as expected :-)

    Just an idea !

    Best Regards,


  • @guy038

    As always, you provided good information, but unfortunately, I don’t think any of it helps the OP in any way with his original problem. :-)

    Regarding the “alt+numpad” method of entry of such characters, what does one do if their keyboard does not have a number pad (like mine)? :-)

    I tried to duplicate the OP’s problem, and I could do it. I then fired up Notepad++ under the Visual Studio debugger…and sadly it worked fine when I ran it that way. :-(

  • @guy038 ,

    I tried (with fresh v7.8.1-64 zip, windows 10) to copy/paste your macro into shortcuts.xml (and reload – not shown), and tried running that macro; still shows the bug. Then I tried to record the macro using the ALT+0133, then playing back that macro: it does the same thing. As I experimented with earlier, the macro works just fine in v7.7.1.


    So, if you’re good at the ALT+#### keysequences, and can remember it, and have a keypad, that’a a valid alternative for a single macro that only inserts the ellipsis. But if any of those conditions aren’t met (including if the ellipsis entry is just part of a larger macro), then the bug in v7.8.1 can insert extra characters (whatever happens to be after that ellipsis in random memory, it appears, because the extra chars change with each program load)

  • Hi, @oasisindesert, @peterjones and @alan-kilborn,

    I did some other tests, including a short text before and after the ellipsis character and… everything still went right !?

    So, Peter, if you don’t mind, I’m going to e-mail you a zip file contening the macro in the shortcuts.xml file and all the minimum amount of files, needed for the N++ 7.8.1 version 32 bits :-))

    This zip file, named ( 1,85 Mb ), contains the following elements ( minimum required ) :

        File Name               Path                    Size       Date Modified
        change.log              N++_781                 2,786       12/11/2019
        config.xml              N++_781                 5,218       28/11/2019
        contextMenu.xml         N++_781                 3,512       25/05/2018
        doLocalConf.xml         N++_781                     0       16/08/2017
        langs.model.xml         N++_781               336,651       27/09/2019
        notepad++.exe           N++_781             2,860,176       27/10/2019
        readme.txt              N++_781                 1,450       26/12/2016
        SciLexer.dll            N++_781             1,264,784       27/10/2019
        session.xml             N++_781                   656       28/11/2019
        shortcuts.xml           N++_781                 1,909       28/11/2019
        stylers.model.xml       N++_781               168,547       27/09/2019
        autoCompletion          N++_781                     0       28/11/2019
        localization            N++_781                     0       28/11/2019
        english.xml             N++_781\localization   76,503       23/10/2019
        plugins                 N++_781                     0       28/11/2019
        Config                  N++_781\plugins             0       28/11/2019
        themes                  N++_781                     0       28/11/2019
        updater                 N++_781                     0       28/11/2019
        userDefineLangs         N++_781                     0       28/11/2019
        Total                                       4,722,192 Bytes

    So, Peter :

    • Extract all contents of the archive, let’s say,; on your destop

    • Double click on the extracted N++_781 folder

    • Rename the Notepad++.guy file as Notepad++.exe     ( Step added the next day : see below for explanations ! )

    • Double click on Notepad++.exe ( 32 bits version )

    • In any already opened file or a new file, just hit the Ctrl + Alt + . shortcut to activate the Ellipsis macro

    => Any shortcut hit writes the string ATGC…ATGC, preceded and followed with a space char, without any problem !

    Now, Alan and @oasisindesert, if you would test my archive file, just e-mail me a short message to :

    Best regards


  • Hi, @oasisindesert, @peterjones and @alan-kilborn,

    I should have tried to e-mail my zip file first, because while sending to Peter, I got the message :

    The message was blocked because its content presents a potential 5.7.0 security issue ?!

    I even tried to rename the as N++_781.guy, but no chance, either :-(

    Now, may be this behavior only happens with a x64 version ? I’m really not convinced !



  • Hi, @oasisindesert, @peterjones and @alan-kilborn,

    This morning, an idea popped up in my brain ! Why don’t I try to rename notepad++.exe as notepad++.guy, in the archive ?

    Bingo ! This time, this attached archive was accepted ;-)) So, Peter, just an additional step to do :

    • Once you have opened the N++_781 folder, rename the notepad++.guy file as notepad++.exe

    You should be able to test my version !



  • @guy038 said in Control symbols now inserted on macro:

    Now, may be this behavior only happens with a x64 version ? I’m really not convinced !

    I am convinced.

    With either the npp 7.8.1 32-bit portable that Guy sent me, or a fresh zip copy from the download page, the 32-bit works with either the pre-packaged shortcuts.xml that Guy sent, or doing a new macro recording of ALT+0133. If I take that exact same shortcuts.xml, and copy it into a fresh unzip of v7.8.1-64bit, the macro shows the bug we’ve been describing.

    Looking at issue#7642, it appears that @xylographe agrees that it happens on 64-bit and not 32-bit, but @rddim doesn’t see it on 64-bit on Win7. Mine is Win 10. So it might be a 64-bit Win10-only instance of the bug. Wow.

  • Might be an ANSI vs. unicode related issue as well?

  • @Ekopalypse said in Control symbols now inserted on macro:

    Might be an ANSI vs. unicode related issue as well?


    I just took Guy’s edition, and ran his macro once in a new file with Encoding > ANSI set, and it worked as Guy described. Then I made a new file, set Encoding > UTF-8, and the bug showed itself – same load of the program, same shortcuts.xml.

  • Hi, @oasisindesert, @peterjones, @alan-kilborn, @ekopalypse and all

    Peter, by rereading your last post, this morning, you said :

    I just took Guy’s edition, and ran his macro once in a new file with Encoding > ANSI set, and it worked as Guy described. Then I made a new file, set Encoding > UTF-8, and the bug showed itself – same load of the program, same shortcuts.xml.

    May be, I’m missing something obvious !

    Opening N++ with the archive that I sent you, the default encoding of new 1 is UTF-8

    But, after numerous tests, using, first, any option of the Encoding menu and, even, the options Encoding > Character Set > ... > from Windows-1250 to Windows-1258, which stand for the main ANSI encodings, then running the macro, I’ve never noticed any control character wrongly inserted !?

    So, I suppose that the main point is to have an old 32-bit operating system and, therefore, to use the 32 bits version of N++, as well. In that case, the bug never seems to be happening !

    Best Regards


  • So, to summarize, the current state is that

    32bit version is not affected at all
    64bit version works with document codec set to one of the 8bit encodings
    and the troublesome is
    64bit version with documents having unicode encoding.

    Which leads to the assumption that macros working on a unicode text
    with 64bit npp version has a bug.

  • @Ekopalypse said in Control symbols now inserted on macro:

    32bit version is not affected at all

    I disagree. As described above, by manually setting the Encoding > UTF-8 toggle, I replicated the bug in 7.8.1-32bit

  • Not sure if this is helpful in this case but using
    Linux and Wine I don’t see the problem on a 64bit version at all.

    Notepad++ v7.8.1 (64-bit)
    Build time : Oct 27 2019 - 22:57:19
    Path : Z:\home…\notepad-plus-plus\notepad-plus-plus.exe
    Admin mode : ON
    Local Conf mode : ON
    OS Name : Microsoft Windows 7 (64-bit)
    OS Build : 7601.0
    WINE : 3.0.4
    Plugins : mimeTools.dll NppConverter.dll NppExport.dll


  • @Ekopalypse : weird.

    To re-confirm what I said earlier today, here’s a screenshot of the bug in action in NPP-32bit on Win10-64bit, showing encoding-dependency:

    • @PeterJones: With both 7.8.1-64bit and 7.8.1-32bit on 64bit Win10 Home 1903 18362.476,
      • Shows with Encoding > UTF-8 but not with Encoding > ANSI
    • @guy038: In WinXP 32bit (@guy038), 7.8.1-32bit, it appears to not show the bug
    • @Ekopalypse: In Linux WINE 3.0.4 with Guest=Win7-64bit 7601.0, NPP 7.8.1-64bit, the bug does not show in either UTF-8 or ANSI

    Strange bug.

  • updated with the new screenshot and the summary of my experiments, @guy038 results, and @Ekopalypse results (ie, basically, copied my last post to github issue)

Log in to reply