Yes I see what you illustrated on my laptop but not on my desktop.

I just updated styers.xml on my desktop and all is wonderful.

Many thanks,
DG

it “dropped down” a second line

This is called a Scintilla “annotation”.

I use it in my “python-check-syntax-on-save” script to produce some information that saves me the time of not finding that problem when I run the script, but rather when I save the file.

An example:

So I know I did an “oopsie” and need to move my from __future__ ... line upward, like this, where all is good:

This little syntax checker was inspired by @dail 's which is for Lua: https://dail8859.github.io/LuaScript/examples/luasyntaxchecker.lua.html

@Alan-Kilborn

Actualy, I am @PeterJones, not @Alan-Kilborn,

I doubt it’s actually nothing. Well actually it is! The console shows nothing at all after the ‘ready’ when I run the script ??

I have to assume it was doing something if it was running. It just wasn’t printing to the console. Edit: but yes, as Alan suggested, I was expecting an error message. When you didn’t see one, I started experimenting more once I had time.

Please remember, you are asking about a script that @Ekopalypse wrote a year ago, which I hadn’t ever used. So I’m sorry that I wasn’t able to describe exactly how it should work off the top of my head without ever looking at it.

*Python 2.7.18 (v2.7.18:8d21aa21f2, Apr 20 2020, 13:25:05) [MSC v.1500 64 bit (AMD64)]
This seems to be reporting an AMD processor which it isn’t! It is an Intel i5-6400 ??

Actually, that’s just what Python reports when it’s compiled in 64bit mode: it’s a historical artifact of the fact that AMD beat Intel to the punch for 64bit architecture on consumer PCs, from what I remember; compilers were often hardcoded with “AMD” in the result, and that’s just stuck because it’s what software developers got used to seeing (and checking) when verifying that it compiled correctly, presumably much to Intel’s chagrin. You can see this even from your cmd.exe prompt :

C:\Users\Peter>echo %PROCESSOR_ARCHITECTURE%
AMD64
C:\Users\Peter>echo %PROCESSOR_IDENTIFIER%
Intel64 Family 6 Model 158 Stepping 13, GenuineIntel

… where it shows it knows it’s an intel chip, but the architecture is still listed as AMD64.

In other words: you haven’t given us enough to go on. Fair comment, but I am not sure what I can add? Here is a sample of the data but I doubt that is relevant.

Sorry, I hadn’t noticed the example “intel hex” document in the initial piece of this conversation. I asked for example data because without seeing that example data that you presented now (or going back and seeing it at the beginning), I had no idea what the data would look like, so I had no way of giving the script valid data.

I ran the script, and it didn’t immediately do anything, so I went back and re-read the entire thread (seeing the original data… sorry) to see if it gave clues; then glanced through to the source code for print statements; I found if I changed self.debug_mode = False to self.debug_mode = True, it would enable a print. When I reran the script, I saw it print a single checksum. Given it was more than one line of data, I was surprised it only showed one. I clicked somewhere else, and it printed another. So then I started arrowing through. When I got to the first line (the one that had an error highlighted), it “dropped down” a second line after the first, where it showed a separate checksum lined up with the incorrect checksum:

Not the best color choice (IMO), but it shows EB instead of F5 as the correct checksum. When I change F5 to EB, the syntax highlighter changes from red to green, and the “dropped down” line goes away.

Does it behave the same way for you? If not, turn on the debug printing by changing the line of code, saving, and re-running the script, and look at the console output as you run it. It should look like:

Once you know it’s working, then you can change that back to False. Exit Notepad++ and re-enter. The next time you run the script, it won’t be printing to the console anymore, but it should show you the fixed checksums.

(And as an aside, you only have to run the script once per load of Notepad++; for that entire session, anytime you enter an Intel HEX document, it will do the checksum as you navigate through the document.)

You said last year,

BTW I am still none the wiser as to why my desktop PC only wants to show Intel Hex in monochrome ??

I had a similar problem: I was using recent v8.1.5, and no highlighting was done for Intel HEX files, even though it was properly recognized as such in the Language Menu. And when I checked the Style Configurator, it didn’t even list it… which meant my stylers.xml didn’t have Intel HEX defined – that probably means that my original installation was from a version that didn’t have that, and since upgrades don’t overwrite an installed stylers.xml, I never got a copy,even though the current repo shows it’s definitely there. I went and downloaded a portable v7.8.9 (which was the rev listed earlier in the thread), and it properly worked. So I looked at my installed %AppData%\Notepad++\stylers.xml, and it was missing the Intel HEX section. So I remedied that:

1. exit my installed notepad++ and restart the app (see usermanual: “editing configuration files” for best practice sequence, which these instructions follow)
2. open c:\Program Files\Notepad++\stylers.model.xml and %AppData%\Notepad++\stylers.xml (see forum FAQ: “what is appdata” and usermanual: “config file locations”)
3. copy the <LexerType name="ihex" desc="Intel HEX" ext="">...</LexerType> from the .model to the appdata, and save
   • If your stylers.model.xml doesn’t have it, copy from the online copy of the file instead
4. exit Notepad++ and restart the app
5. now v8.1.5 properly syntax-highlights

The console shows nothing at all after the ‘ready’ when I run the script ??

I think that @PeterJones was hopeful that some sort of error message would be produced. As nothing of that ilk appears to be showing, it would seem the script is functioning as @Ekopalypse intended, just maybe not for you.

Python 2.7.18 (v2.7.18:8d21aa21f2, Apr 20 2020, 13:25:05) [MSC v.1500 64 bit (AMD64)]

I’ve never really considered this before, but I think it (the “AMD”) is probably what PythonScript was built with? Or the Python exe it uses was built with it? Regardless, I don’t think it has anything to do with what machine it is currently running on.

At least you didn’t complain that it isn’t showing the current date but is rather showing Apr 20 2020 (that’s a total joke, but it adds support to that this info is being pulled from somewhere other than your current machine).

@Alan-Kilborn
I doubt it’s actually nothing. Well actually it is! The console shows nothing at all after the ‘ready’ when I run the script ??

Python 2.7.18 (v2.7.18:8d21aa21f2, Apr 20 2020, 13:25:05) [MSC v.1500 64 bit (AMD64)]
Initialisation took 297ms
Ready.

This seems to be reporting an AMD processor which it isn’t! It is an Intel i5-6400 ??

In other words: you haven’t given us enough to go on. Fair comment, but I am not sure what I can add? Here is a sample of the data but I doubt that is relevant.

:10000000FF050102FFFFFFFFFFFFFFFFFFFF09FFF5
:10001000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF0
:10002000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFE0
:10003000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFD0
:10004000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFC0
:10005000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFB0
:10006000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFA0
:10007000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF90
:00000001FF

Both machines are running Win10 Home. Obviously the screen drivers are different. Both running the latest version of NPP.

Are there any config files I can send?

Cheers, DG

When I open a file containing 9 lines of Intel Hex and run the script, precisely nothing happens ??

I doubt it’s actually nothing. Fortunately, PythonScript has a console which is useful for debugging: go to the PythonScript menu and show the console, and see if it shows any errors after you run the script.

This is on my desktop which does not show the highlighting of the hex file. I then tried on my laptop, which does the highlighting correctly, and the script works.

So obviously there is something different between the two setups.

So back to the original question, why does my desktop not show the highlighting? Both running NPP v8.1.5

My magic eight ball says “Reply hazy, try again” and then “Concentrate and ask again”. In other words: you haven’t given us enough to go on. You’ll have to provide more information, including the PythonScript console results, and maybe some example data.

sorry I only just noticed it. Better late than never

Wow, that was a long layoff…

Where should I save the file and how do invoke the script?

There are some basic instructions for this type of scripting HERE. See the PeterJones Jan 19, 2021 4:12pm posting.

Sorry, I was busy with some personal matters.
Here’s a python script that hopefully does what you want. If there is something else you might want to have or it doesn’t do what you want it to be done I would kindly ask to use the github issue tracker in my repo.

N++ … does know how to calculate the checksum

Notepad++ code has absolutely no idea how to do this checksum.
It isn’t doing it.
The underlying lexer is doing it, which comes from a separate project, called Scintilla.

I know how to calculate the checksum but so does N++ and I would like it to be automatically calculated for me when I edit a line.

This goes beyond the responsibility N++ signs up for. :-)
You could certainly do something for it with a scripting plugin, e.g. Pythonscript.

BTW I am still none the wiser as to why my desktop PC only wants to show Intel Hex in monochrome ??

So to add transparency to current line background, it would have to be a codebase edit.

I did some searching and found THIS as probably related.

isn’t there a way to do something to the current-line-background color so that you can just get the red there (or close

I think the problem isn’t that the red has transparency; I think the problem is that the current-line-background has no transparency and is drawn over the red, so the current-line-background is the only visible background. It might be possible if the current-line-transparency could be set to 50% or something of that ilk, but that cannot be done in the GUI.

I tried editing stylers.xml to use either the MSB or LSB as an alpha value for the current line background

        <WidgetStyle name="Current line background colour" styleID="0" bgColor="E8E8FF80" colorStyle="1" fontStyle="0" />
or
        <WidgetStyle name="Current line background colour" styleID="0" bgColor="80E8E8FF" colorStyle="1" fontStyle="0" />

But either was interpreted as invalid color, and current-line-background became black.

So to add transparency to current line background, it would have to be a codebase edit.

Change the foreground color of CHECKSUM_WRONG to something that contrasts both with its red background color and with your Global Styles > Current Line Background > Background color.

Well…yea…but I meant, isn’t there a way to do something to the current-line-background color so that you can just get the red there (or close to it due to blending of colors) for the non-current line case?

What’s the way around that, if any?

Change the foreground color of CHECKSUM_WRONG to something that contrasts both with its red background color and with your Global Styles > Current Line Background > Background color.

BTW, it’s work pointing out that the background color of the CHECKSUM and CHECKSUM_WRONG styles of the Intel Hex language are totally transparent ( α = 0 ) So, for instance, the default red background of a wrong checksum is not visible if this line is the current N++ line with usual very pale blue background color !

Interesting. What’s the way around that, if any?

You can find a good documentation on the Intel Hex File Format from below :

https://developer.arm.com/documentation/ka003292/latest

https://en.wikipedia.org/wiki/Intel_HEX

And I deduced that the checksum can be calculated from this formula :

CheckSum = 256 - ( ∑ Byte Values ) MOD 256

Each Byte Value represents the decimal value of the next two hexadecimal codes, minus the last two ones, standing for the checksum

For instance, the fourth line, of your example, is :

                                         vv----- CheckSum
:10004C001D7F1093040410E008EC74D114E110939C
 <-------------------------------------->        Data Range

So its checksum is :

 
= 256 - (10h + 00h + 4Ch + 00h + 1Dh + 7Fh + 10h + 93h + 04h + 04h + 10h + E0h + 08h + ECh + 74h + D1h + 14h + E1h + 10h + 93h) mod 256

= 256 - ( 16 +   0  + 76  +  0  + 29 + 127 +  16 + 147 +   4 +   4 + 16  + 224  +  8 + 236 + 116 + 209 +  20 + 225 +  16 + 147) mod 256

= 256 - 1636 mod 256

= 256 - 100

Thus, the checksum of the fourth line is 156 , so 9C

BTW, it’s work pointing out that the background color of the CHECKSUM and CHECKSUM_WRONG styles of the Intel Hex language are totally transparent ( α = 0 ) So, for instance, the default red background of a wrong checksum is not visible if this line is the current N++ line with usual very pale blue background color !

Best Regards,

guy038

I guess really ambitious lexing!

Lol
It would be nice if the builtin lexers would show code which isn’t efficient :-D