

Public string Decode( string encodedtext, string pass)īyte data = Convert.FromBase64String(encodedtext) String result = Convert.ToBase64String(data) Public string Encode( string cleartext, string pass)īyte data = (cleartext) The main part is made of the very simple interface IEncoder, and the way it is used in Main.cs. These classes may be found in the ' PluginInfrastructure' folder. The backbone of this plugin is made by the standard plugin classes, automatically generated by the plugin template. The Notepad++ version used was Npp 8.3.3, 64bit. This Npp plugin was created by using the Npp plugin template v0.94.00: a new DLL containing the algorithm I want to test, defined in a class inheriting a very simple interface (defined in the Npp plugin).Weird, right? So, now, when I want to test an algorithm, I need two things:

Then I modified it (the Npp plugin), so that it allows his plugins too. So I thought: why don't I use Notepad++ as an interface? That's why I ended up writing a plugin for Notepad++ (which I'll address as Npp from here on). because an algorithm is fun, and the interface is not. Sometimes, that algorithm is related to cryptography or encoding and I want to try it directly without having to write an interface.
