How to create a C# plugin?

Ekopalypse

@scampsd said in How to create a C# plugin?:

that search feature can mark only a token, not the entire line, and in top of that only five tokens can be added. Is that correct?

Yes

Without the information of what you have done, it is hard to say what is wrong. At the moment I assume that you have not chosen the right indicator.

alt text

PeterJones

@scampsd said in How to create a C# plugin?:

As far as I’ve understood, that search feature can mark only a token, not the entire line

The Search > Mark dialog’s “Mark” feature uses a different Mark style (Global styles > Find Mark Style), separate from the 5 “token” styles (Global styles > Mark Style #). They are two separate features.

The Search > Style xxx Token actions are controlled by the Settings > Preferences > Highlighting > Style All Occurrences of Token settings as to whether they require one true word/token (checkmarked option), or whether it allows part of a word or extending over multiple words. There is no way to set it to “style entire line when token XYZ is present”, but if the checkbox is not checkmarked, and the selection covers the whole line when Search > Style One Token > Using Nth Style is run, then that whole line will be styled.

and in top of that only five tokens can be added. Is that correct? (I’m asking this because in case the entire line can be coloured and more than five tokens are possible, it makes no sense developing the plugin I’m currently working on).

Tokens can be combined: here’s an example of line 1 using 1st token style, line 2 in 2nd token style, and line 3 in both 1st and 2nd applied – they have partial “alpha”/transparency, so they can “add” the colors together:

(so one and two is highlighted both cyan and peach, coming out as a pale greenish color)

With 5 token styles, and the binary choices of “yes” or “no” on each of those, it’s actually 2⁵=32 different combinations of token-styles that can be applied. If 32 distinct sum-of-colors is sufficient for you, then the style-token could help you. But, again, you cannot say “any line that contains | Trace | gets Style 1 for the whole line”. So the token-styler probably won’t meet your needs, alone. But if you cannot get your plugin to apply the Indicator in the way you like, you might be able to switch it to applying some combination of the 5 token-styles.

Mark Olson

@PeterJones mentioned the Search > Mark feature, which moves in the direction of what @scampsd was asking for.

Given that background color customization specifically is requested, the Marker API (~~which is what the Search > Mark feature uses under the hood~~ (EDIT: corrected a false assertion)) could be used instead of the Indicator API.

I have not used Markers at all, so @scampsd would need to figure out how to use it by reading the documentation I linked above.

PeterJones

@Mark-Olson said in How to create a C# plugin?:

the Marker API (which is what the Search > Mark feature uses under the hood) could be used instead of the Indicator API.

The first paragraph of the Marker API docs say, “Markers appear in the selection margin to the left of the text.” They are the margin symbols like the folding symbols, as shown in the image on that page:

I don’t think the Search > Mark highlighting is done with Markers.

The Smart Matching, Tag Matching, and Token Styles are all done with indicators.

And the stylers.model.xml “Find Mark Style” is StyleID#31 SCE_UNIVERSAL_FOUND_STYLE – and when you do the Search > JumpUp/JumpDown to the “Find Mark Style”, it runs this case, where it searches for the next indicator with value SCE_UNIVERSAL_FOUND_STYLE = 31. So I’m pretty sure that the Search > Mark is also using an Indicator, just like the Smart/Tag/Token, above.

Ekopalypse

@Mark-Olson said in How to create a C# plugin?:

the Marker API

and it has a really nice feature, it provides calls to jump to next or previous marks.

Alan Kilborn

@PeterJones said:

The first paragraph of the Marker API docs say, “Markers appear in the selection margin to the left of the text.”

It says that, but it is not 100% true.
If one uses SC_MARK_BACKGROUND or SC_MARK_UNDERLINE, the result is not in the margin, but rather in the text itself (as the graphical image that shows the examples–above, in Peter’s most-recent post–implies).

Entire-line coloring seems to be what @scampsd is trying to achieve, so perhaps using marker(s) with SC_MARK_BACKGROUND will be useful.

scampsd

@Alan-Kilborn Sorry for the late reply: I don’t have the time to work on this matter every day.

If I understand well, I seem to have the following choices:

Indicators : this is something which might work, but the provided example is based on the method Npp.notepad.AllocateIndicators(numberOfIndicators, out int[] indicators), which is not very clear yet.
Styles : if I understood correctly, the maximum number of styles (being 5) is not only a limitation for Notepad++ users, but also for Notepad++ plugin developers.
Markers : again another approach.

If you don’t mind, I’d like to proceed with the “Indicators” approach, but then I need to understand the AllocateIndicators() method, and it looks really not simple: the provided example launches that method and as a result, a list of indicators seems to be linked with some individual characters, present in the text.
I have done the following modifications to the example:

for (int ii = firstIndicator; ii <= lastIndicator; ii++)
{
    Npp.editor.SetIndicatorCurrent(ii);
    Npp.editor.IndicSetFore(ii, new Colour(255, 0, 0)); // Colour RED
    Npp.editor.IndicSetStyle(ii, IndicatorStyle.FULLBOX); // Use full rectangle
    Npp.editor.IndicatorFillRange(ii, 5); // Not one but five characters long
}

The result is the following:

Can anybody explain me why the mentioned indicators get linked to the 9th, the 10th, … up to the 14th character? How can I change that and link those indicators to other characters, words, lines, …?

Ekopalypse

@scampsd said in How to create a C# plugin?:

Can anybody explain me why the mentioned indicators get linked to the 9th, the 10th

You have used the IDs as the starting position.

SCI_INDICATORFILLRANGE(position start, position lengthFill)

Mark Olson

@scampsd
So the purpose of AllocateIndicators is to tell Notepad++ that you want to use a certain number of indicators. Based on how many indicators you requested, Notepad++ tells you which ones you can use (that’s the out int[] parameter). These are reserved for you for the rest of the session.

Once you have the indicators, you customize their appearance using methods like IndicSetStyle and IndicSetFore. You can do this once at startup; once you’ve customized the style it stays that way for the rest of the session.

To style a given region of a document with an indicator, use SetIndicatorCurrent and IndicatorFillRange.

To find all the regions of a document that are styled with a given indicator, use IndicatorStart, IndicatorEnd, and IndicatorValueAt as shown in this example from JsonTools.

scampsd

@Ekopalypse Thanks, I get that now.
I’m succeeding colouring some pieces of text now but you might imagine the next question: the method Npp.editor.IndicatorFillRange(int start, int length) is, as you mentioned, depending on start integer and length integer, while I’m working with entire lines.

I’m obviously capable to calculate the start and length, based on content of “| Trace |” or “| Debug |” and the newline characters (hardcoded "\r\n"), but I’m wondering if there’s not an easier way to work with lines of text in the editor.

Alan Kilborn

@scampsd said:

an easier way to work with lines of text in the editor.

I think you need to spend some time getting more familiar with the editor API, i.e., the Scintilla documentation (a portion of which was linked to earlier). It has everything you’ll need.

Mark Olson

@scampsd

I’m obviously capable to calculate the start and length

Be careful! Notepad++ uses UTF-8 to encode its buffers so you need to use JsonParser.ExtraUTF8Bytes and JsonParser.ExtraUTF8BytesBetween if you want to convert between indices in your C# strings and positions in the document.

EDIT: this is only necessary if your plugin will be running on files that contain non-ASCII characters.

PeterJones

@Alan-Kilborn said in How to create a C# plugin?:

I think you need to spend some time getting more familiar with the editor API, i.e., the Scintilla documentation (a portion of which was linked to earlier). It has everything you’ll need.

While that is good advice, for someone just getting started, it’s knowing where to look in that rather big document, or the right search terms, that is the difficulty.

For example, I’m not sure it’s natural to me to look in the “Information” section to find the commands that convert between position and line, and whether to search for line start or start line or start of line or start of the line. (And of course, a search for line or start alone finds way too many to help narrow things down.) (And yes, I did intentionally pick those examples to throw @scampsd a bone to help narrow down the search range for solving the immediate problem.)

Even as someone who has done a lot of interacting with Scintilla through the PythonScript interface, I can find it difficult to find the right command that I’m looking for, because I use the wrong term, or I don’t go to the right subsection to find the right group of commands to be able to find the one I’m looking for.

Coises

@Mark-Olson said in How to create a C# plugin?:

Notepad++ uses UTF-8 to encode its buffers

I don’t know C# or the C# interface, so this might not be relevant there, but in general, Notepad++ may work with Scintilla using UTF-8 or “ANSI” — ANSI being the system default Windows ANSI code page. SCI_GETCODEPAGE tells you which it is; in Notepad++ it is always either CP_ACP or CP_UTF8. (Defined, for example, here.)

I’m not sure how that translates to the C# functions you mentioned, but there are non-ASCII characters (128 of them, different ones for each code page) that can still be represented in ANSI mode. Like any ANSI character, they take up one position in Scintilla, not the number of positions the corresponding UTF-8 character would require.

rdipardo

@Coises said in How to create a C# plugin?:

I’m not sure how that translates to the C# functions you mentioned, but there are non-ASCII characters (128 of them, different ones for each code page) that can still be represented in ANSI mode.

See how my .NET Core template wraps all of Scintilla’s text manipulation APIs in a private method that takes account of the document’s encoding (which may be single-byte ASCII), converting to a properly encoded byte array before the window procedure call. (Note: CodePage is the name of an interface property, which .NET Framework apparently supports, since the class library is multi-targeted.)

Alan Kilborn

I said:

I think you need to spend some time getting more familiar with the editor API, i.e., the Scintilla documentation (a portion of which was linked to earlier). It has everything you’ll need.

@PeterJones said:

While that is good advice, for someone just getting started, it’s knowing where to look in that rather big document, or the right search terms, that is the difficulty.

I said what I said because I was feeling like this topic was heading in the direction of potentially a lot of spoon-feeding. Everyone should spend time with the documentation when they’re using something new, and ask detailed questions when those questions are really needed.

Ekopalypse

@scampsd

Another possibility would be to use the internal search engine of Npp and thus avoid the encoding problem.
This means using SCI_SEARCHINTARGET with a corresponding regular expression in a loop and then SCI_GETTARGETSTART and SCI_GETTARGETEND to determine the positions. SCI_GETTARGETEND then becomes the next start position for SCI_SEARCHINTARGET …

scampsd

@Ekopalypse : Let me start by thanking all of you for the wonderful support I’m getting from you guys.

At this moment I’m at the stage that I’m having the following pieces of source code:

int iAmountOfLines = Npp.editor.GetLineCount();
for (int i = 0 ; i < iAmountOfLines; i++)
{
    string strCurrentLine = Npp.editor.GetLine(i);
    if (strCurrentLine.IndexOf(Txt_Trace) != -1)
    {
        Npp.editor.SetIndicatorCurrent(0); // Trace
        Npp.editor.IndicatorFillRange(Npp.editor.GetLineEndPosition(i) - strCurrentLine.Length, Npp.editor.GetLineEndPosition(i));
    }

The “if”-clause is being repeated for all log levels, and it is currently giving the following output (not correct, but very promising 😀):

When seeing that, you might wonder how I have configured the corresponding colours. Well, me too 😥. Let me show you what I mean: this is what I see when I open the corresponding configuration form:

“But Dominique, you didn’t configure your colours?”

Well, I did, but I forgot two things:

Using the already configured colours while re-opening the configuration form, I’ll take care of that.
Saving the already configured colours in registry, in order to avoid needing to re-configure the whole thing every time I perform a test.

About that last part, I have the simple question: “Where?”.

For your information, this is what my registry looks like at “HKey_Local_Machine\SOFTWARE”:

You might notice two things:

There is another tool (Mozilla), having its plugins configured around that place.
There are no Notepad++ plugins being configured around that place. (Although I have some Notepad++ plugins I’ve used before)

Can anybody confirm if I’m at the right spot for saving Notepad++ plugin configurations? If not, what’s a place which is better suited?

Thanks in advance (again)

Ekopalypse

@scampsd

Although the registry is actually the Windows standard, I would personally avoid it and rather use the plugin config directory. Can be determined via NPPM_GETPLUGINSCONFIGDIR.
However, I would create a subdirectory with the plugin name and add a json, xml, toml … file there.