Plugin DLL becomes incompatible after calling CreateLexer()

Thomas Knoefel

I’ve been working rigorously on implementing a lexer, but I’ve hit a roadblock. My goal is to incorporate a lexer into a plugin, which can be toggled from the panel.

I adapted the SimpleLexer.cxx to suit my needs and renamed it to MultiReplaceLexer.cpp. The lexer was initialized as follows:

static LexerModule lmSimple(SCLEX_COLUMNS, LexerSimple::LexerFactorySimple, "simple", nullptr);

However, when I try to invoke CreateLexer(lexerName); in MultiReplacePanel.cpp, I encounter an issue. Once CreateLexer() is added, Notepad++ displays an error stating:

MultiReplacePanel.dll is not compatible with the current version of Notepad++.

To set up the environment, I built the platform libraries for both Scintilla and Lexilla. Perhaps there’s a more straightforward method to achieve this? For this task, I utilized the most recent versions of Scintilla (v536) and Lexilla(v526). Is it possible that there’s a compatibility issue between Notepad++ v8.5.6 and these versions? I’d like to be sure before I invest more time in setting up new libraries.

If anyone is interested in inspecting the code in-depth, I’ve created a new branch named feature/lexer for this purpose or just click on the links in the post. Thanks!

PS: I also find it a bit strange to put all *.cxx from lexlib directory into the VS Project as they are not part of the Lexilla.lib. Maybe I had a wrong approach with my first testings?

rdipardo

@Thomas-Knoefel,

PS: I also find it a bit strange to put all *.cxx from lexlib directory into the VS Project as they are not part of the Lexilla.lib. Maybe I had a wrong approach with my first testings?

I recommend studying this basic example of an ILexer5 implementation to see what headers (and only headers) you will need. All of them are included in the Notepad++ source tree. You can use a git submodule to keep the N++ code up to date.

Apart from that, an external lexer is just an ordinary plugin that exports at least 3 additional functions, listed here: https://community.notepad-plus-plus.org/post/83136

I say “at least” because N++ 8.3.3 and older versions will crash unless GetLexerFactory and GetLexerStatusText is exported as well. Implementing these would only be necessary if you wanted to preserve backward compatibility, but they can safely co-exist with the newer functions that replaced them in version 8.4. N++ will ignore the exports it doesn’t know about, so an “over-provisioned” library is not a problem.

Some lexer plugins are even backward compatible in spite of themselves, simply because the maintainer didn’t bother to rip out the obsolete functions. See, for example, https://community.notepad-plus-plus.org/post/86142

Thomas Knoefel

@rdipardo Thank you for the insightful information. The example is indeed very helpful. I managed to get it up and running quickly. It should serve as a good template for the next steps. It’s a good reminder of why I give projects a star on GitHub. It certainly makes sense to take N++ as the source for the compile.
My initial guess is that the versions of Scintilla and Lexilla i used are not compatible with N++. I’ll proceed with the next test, i hope with better luck ;-)

Thomas Knoefel

@Thomas-Knoefel Just a short update on my achievements. I managed to compile everything using the original N++ sources. However, upon further investigation, I realized that if I wanted to use the Lexer, I would need to adapt a lot of code to fit into the plugins framework.
I decided to run some tests by setting the styles without a Lexer. Remarkably, I found that using Styles instead of Indicatorstyles (which I initially used for my first test) was much faster than expected.
Surprisingly, the speed almost matches that of a Lexer (even if it is 3 times slower, it still offers good usability for that purpose).But i think i will probably leave the N++ Source Code next to the Plugin to have a better updated in future for some other files.