@PeterJones said:

I am assuming you never passed the const char configFile[] to a N++ message.

I do not pass the string anywhere and it already affects the plugin acceptance. It is just declared and that is all. It might be some bug in MinGW itself but I am not able to judge. If I remove the initialization and have static const string configFile; the plugin is ok, too.

In the meantime I upgraded to version 8.9.6.4 (the newest one) but it behaves the same.

Is there a way how to debug what is going wrong when plugin is opened ?

@medvidec said:

NPP version is 8.6.4 - not the newest one but not too old either.

I mean, that was from Feb 2024 (more than two years ago), and there’s been roughly 35 newer versions released in the intervening time. In software, 2+ years is ancient.

That’s almost-definitely not the cause of your problem in this instance, but there have been a large number of important security fixes over that period, and choosing to not upgrade means your Notepad++ version has known and published security vulnerabilities (with exploits active in the wild), so it is much less secure than a modern Notepad++ version.

I would normally ask that you check to make sure that your compiler’s bitness matches your N++ bitness (since I forget MinGW’s official naming scheme), but given that it works when you use const char configFile[], you’ve presumably got that all worked out.

There’s nothing specific about string which makes a plugin incompatible with N++ – or, at least, I use std::string and std::wstring throughout my MSVC-based plugins all the time. There shouldn’t be any difference in syntax for strings betwen MSVC and MinGW.

But std::string isn’t 100% drop-in replacement for char*: if you are passing to an API that requires char* (+), you would need to switch to configFile.c_str() or configFile.data() where the char* version of the variable just used configFile. So that would be the first avenue of exploration I’d go down in debugging – seeing whether the function calls that are using configFile are compatible with string, or whether you need to extract the raw c-style pointer out of the std::string object.

(And having to build the std::string interface in the DLL, vs being able to use pure-c++ char-manipulation could increase the DLL size significantly, so depending on the size of your plugin, that could “double” it.)

+: The N++ plugin-communication messages are almost all wchar_t*-based (with one or two char*), not std::string based. Because of that, I am assuming you never passed the const char configFile[] to a N++ message without conversion, so I don’t think it’s the NPP API that’s causing the problem. But there are a lot of win32 API calls that require char* or wchar_t*, so passing in a string or wstring to one of those would not work, and you’d instead