@rdipardo said in Generalized fix for Ctrl+C/X woes in C# plugins (beginning in Notepad++ 8.6.1):
Don Ho obviously took for granted that every plugin would be developed on the same toolchain as the host application. And C++ developers have mostly vindicated that assumption by using Microsoft’s Visual C++ compiler almost exclusively. Plugins built with GCC are even harder to find than non-C++ ones.
I don’t draw the same conclusion. It’s possible that I’ve missed something, but as far as I can tell, the plugin interface is strictly C (not C++) and Win32 API. That is as close to generic as you can get under Windows.
Were the interface C++, a GCC plugin probably wouldn’t work. The C ABI is compatible across compilers (and languages); C++ ABIs are not. (They’re not even guaranteed to be compatible between different versions of the same compiler, though generally compiler vendors try really hard not to break things in that way.)
When writing in C++ for Windows only and using the Win32 API, Visual Studio with MSVC is simply the path of least resistance. Unless you have another tool chain already set up, or additional requirements, there is little reason to use GCC, so I’m not surprised it isn’t frequently done. There’s no reason it can’t be done, it’s just extra hassle for no benefit.
I suspect the problem for C# plugins is, strictly speaking, WinForms and not C# itself. WinForms was probably not meant to interoperate with unmanaged Win32 API windows in the same application (especially with Win32 handling the top level windows and the message loop).
If that’s the problem, and if the creators and maintainers of C#/WinForms have not specified any mechanism by which this can be reliably accomplished, then there’s little anyone can do about it except hack around and hope, or refrain from trying to use C#/WinForms for something it is not meant to do.