Need help with getting started using C++ Plugin Template

Ekopalypse

This post is deleted!

PeterJones

@PeterJones said in Need help with getting started using C++ Plugin Template:

if you know of a “best practices” C++ plugin I can use as a reference

For some reason, I thought that @Coises was one of the C# programmers so I didn’t think of looking at Columns++; but I now see it is, in fact, in C++, so I’ll probably at least use it for reference. :-)

Coises

@PeterJones

I was working on a personal project to create a Visual Studio Template for C++ plugins for Notepad++. I put that on hold while I’m working on improving the regular expression search for Unicode files in Columns++.

If you would like to try it as a starting point, I put a copy here:

https://www.coises.com/extrn/SampleNppPlugin1.zip

I don’t have it packaged as a template yet, so the included instructions for installing it don’t apply. Just unzip, put it somewhere you’ll leave it, and double-click the Waiting for Godot.sln file to open it in Visual Studio.

It is a working (though useless) plugin that includes an About dialog, a Settings dialog, a non-modal dialog, a docking panel and a mechanism for saving settings as a JSON file.

The included help file is somewhat out of date, but it will still give you an idea how the thing is organized. As noted at the start of that file:

This project is not a part of Notepad++ and is not endorsed by the author of Notepad++.

This template includes framework code for making a Notepad++ plugin in C++, along with various utility functions and examples.

I have constructed it to give myself and others a useful starting point when developing a Notepad++ plugin in C++.

It necessarily reflects my own idiosyncrasies as a programmer. I hope it may prove useful to others, and I welcome comments, suggestions and problem reports in the Issues; however, I make no apologies for its incorporation of my personal choices and styles — which might not meet with universal approval — and I do not promise to make changes to accommodate all plausible programming styles and use cases. So be it.

Coises

@PeterJones said in Need help with getting started using C++ Plugin Template:

For some reason, I thought that @Coises was one of the C# programmers so I didn’t think of looking at Columns++; but I now see it is, in fact, in C++, so I’ll probably at least use it for reference. :-)

See my previous post about a template I have in progress. Even though it is not finished yet, it is probably a better model than Columns++. It does load and open dialogs.

Columns++ was my first plugin, and I made a few design decisions I would do differently now. It also has a lot of complexity because of what it does… untangling that from what parts are needed to work as a plugin could be confusing.

In the template-in-progress, I’m making an effort to separate the code that needs to be there for a plugin to work from the code that does what your plugin does. If you try it, you can tell me to what extent I’ve succeeded. ;-)

rdipardo

@Coises said in Need help with getting started using C++ Plugin Template:

See my previous post about a template I have in progress.

👍 Looks like a promising object-oriented replacement for Don HO’s mostly C-like template (with its global variables, constants declared with #define instead of constexpr, raw pointers, etc.).

One small tip: if you don’t want the Win API’s min()/max() macros to shadow std::min/*::max, simply put #define NOMINMAX before you include <windows.h> (to hide the macros from the current file), or add NOMINMAX to the project’s compiler definitions (to hide them everywhere). That will slightly clean up the preprocessor kludge at the top of .../src/Framework/PluginFramework.h, i.e.,

// ...
#include <windows.h>
// ...
#undef min
#undef max

Coises

@rdipardo said in Need help with getting started using C++ Plugin Template:

#define NOMINMAX

Thanks! I didn’t know about that.

And thank you for the encouragement. I hope it might be helpful. Every time I think, “Maybe that should just be a plugin of its own,” I shudder at the housekeeping needed to start one. I plan for this to end up as a Visual Studio template that will appear in the “Create a new project” list. (I have that working, but I haven’t updated it with the many changes I’ve already made to the code, so I just made a zip of the trial project that I’ll eventually turn back into a template.)

Alan Kilborn

Picking up from where my previous post in this thread ended…

Hmm, I submitted that post, then I edited it to add more info, and…somehow never submitted that. :-( Maybe there were gremlins in the machine (or the user!)…the same ones that caused my screenshot to somehow be dark…

OK, well, I meant to say that what I’ve done to debug/step a plugin code is “what I said earlier” plus I do some “trickery” to get things in the correct folder scheme so that Notepad++ finds the plugin when it starts up. That trickery involves a symbolic link, so that the plugin development folder can be anywhere but yet also maps to being in the plugins folder underneath Notepad++.

Thus:

In the plugins folder under Notepad++, from a cmd prompt, create the folder for the plugin (md PluginName), and then execute mklink /D PluginName PathToDebugFolderOfPlugin

Alan Kilborn

@Coises said:

Under Build Events, select Post-Build Event

Regarding this approach, it surprises me that it works, because that file is going to be a different file from the one the IDE knows about. When the plugin is “run” under the debugger, the IDE runs Notepad++ (due to the other setup step), but I’d think when it loads the DLL file (copy!), it wouldn’t hit any breakpoints because it would be “keying on” the DLL file (and supporting debug data) it built into the plugin’s Debug folder, not some solitary copy of the file elsewhere in the file system.

Alan Kilborn

@Coises said:

Every time I think, “Maybe that should just be a plugin of its own,” I shudder at the housekeeping needed to start one. I plan for this to end up as a Visual Studio template that will appear in the “Create a new project” list. (I have that working, but I haven’t updated it with the many changes I’ve already made to the code, so I just made a zip of the trial project that I’ll eventually turn back into a template.)

This sounds like a great idea. Others have had a similar idea but I don’t know that anyone has ever taken it so far as to produce a really solid “this IS the C++ plugin template” to use.

Perhaps a collaborative effort with @ThosRTanner (another with a better-plugin-template idea; see HERE ) would be in order.

Coises

@Alan-Kilborn said in Need help with getting started using C++ Plugin Template:

@Coises said:

Under Build Events, select Post-Build Event

Regarding this approach, it surprises me that it works, because that file is going to be a different file from the one the IDE knows about. When the plugin is “run” under the debugger, the IDE runs Notepad++ (due to the other setup step), but I’d think when it loads the DLL file (copy!), it wouldn’t hit any breakpoints because it would be “keying on” the DLL file (and supporting debug data) it built into the plugin’s Debug folder, not some solitary copy of the file elsewhere in the file system.

As I understand it, there is a GUID in compiled modules. When you run the debugger within the project, it has the locations of the source and symbol files. Upon loading a module (exe or dll) the debugger looks to see if it has a symbol file (pdb) for that module name and then checks that the GUIDs match. It doesn’t care from where the module was loaded.

I didn’t figure out that this would work, though… I copied it from somewhere else, I just don’t remember where.

I did make a mistake and an omission in what I wrote earlier (to @PeterJones). %ProgramFiles% works in the Post-Build Event command, but for some reason you have to spell out the actual path in the Debugging command. And to use the automatic copying into Program Files, you have to change the permissions on the Plugins folder so that privilege elevation isn’t required to modify it — OK on a personal development machine, not so good on a shared machine.

PeterJones

@Coises ,

I did make a mistake and an omission in what I wrote earlier (to @PeterJones). %ProgramFiles% works in the Post-Build Event command, but for some reason you have to spell out the actual path in the Debugging command.

I actually figured that out. $(ProgramFiles) works for the Debugging Command –

for some reason

I think the difference is that Post-Build Event is essentially a cmd.exe script, whereas the Debugging Command goes through VS variable substitution then gets sent to something akin to ShellExecute, probably without a cmd.exe wrapper, so it doesn’t know cmd environment variable syntax.

And to use the automatic copying into Program Files, you have to change the permissions on the Plugins folder so that privilege elevation isn’t required to modify it —

Yeah, that “permissions” bit me at first, trying it that way.

I switched over to @Alan-Kilborn’s symbolic link-- but if I do both the mkdir and the mklink, the mklink complains; doing the mklink from the plugins\ directory without doing the mkdir first works to make the psuedo-directory for the plugin.

OK on a personal development machine, not so good on a shared machine.

Interesting to note: the DebuggerCommand seems to be stored in blah.vcxproj.user whereas the PostBuildEvent gets stored in blah.vcxproj (at least in my experiments)… so when multiple people are developing in the same project, but one needs to run $(ProgramFiles)\notepad++\notepad++.exe but the other needs to run c:\path\to\portable\notepad++.exe, the DebuggerCommand can be separate for the two developers. OTOH, if the DLL gets copied to a fixed location in DebuggerCommand, that will try to do the same copy for both users, which wouldn’t work. Having each developer just create the symbolic link from the appropriate plugins\ directory pointing to their local <arch>\Debug directory with the appropriate DLL and meta-information seems to make good logical sense to me

xomx

@Alan-Kilborn said in Need help with getting started using C++ Plugin Template:

, it surprises me that it works, because that file is going to be a different file from the one the IDE knows about.

@Coises is right. There is a PDB (debug symbols file, which binds together the source code and its binary) location info inside the binary PE-header. It’s not a GUID but simply an original path to the PDB-file. A sample of that info from my custom PythonScript plugin:

Alan Kilborn

@xomx said in Need help with getting started using C++ Plugin Template:

simply an original path to the PDB-file

Ah, so as long as that file stays where it is, the project can be “debugged” from the IDE no matter where the DLL is located. Ok, well, thanks for filling in that little nugget of seemingly missing info!

…from my custom PythonScript plugin

Oooh. What kind of customizations? :-)

Alan Kilborn

@PeterJones said in Need help with getting started using C++ Plugin Template:

but if I do both the mkdir and the mklink, the mklink complains; doing the mklink from the plugins\ directory without doing the mkdir first works to make the psuedo-directory for the plugin.

Ah, sorry about that detail; I was going from some old notes I had rather than actually trying it out. :-(
Good that you got it working, though.

xomx

@Alan-Kilborn said in Need help with getting started using C++ Plugin Template:

from my custom PythonScript plugin
Oooh. What kind of customizations? :-)

Sorry, no new functionality if you expected so - that was just a slightly debugging enhanced version for fixing the PS-console not showing bug after N++ relaunching.

ThosRTanner

@PeterJones as far as building goes, I’ve never had any problems building notepad++ i normal mode and my dll in debug mode. However, it’s a littel tricky getting n++ to recognise your dll. You have to either hijack another plugin’s directory, or go to plugin admin mode and point it to a zip file you’ve built.

Some instructions on installing a plugin manually (pretty sure you wrote them) are here: https://github.com/ThosRTanner/notepad-pp-linter/blob/master/README.md

But to build it, you’ll need to add a post build step - see https://github.com/ThosRTanner/notepad-pp-linter/blob/master/post-build.ps1 or https://github.com/ThosRTanner/Docking_Dialogue_Interface/blob/master/post-build.ps1 for examples on that.

You also need to customise the debug command to point to the actual notepad++ exe (doesn’t need the debug version) - then the debugger loads up notepad+ and will hit the breakpoints in your dll

PeterJones

I’ve been making “good” progress on this plugin. (Or, at least, good for me, considering I have never written a real plugin before.)

I stuck with the original template for this plugin, since I’d already started, but I will be trying out @Coises’s VS Template for my next. Though I still maintain that Don’s grandmom is brilliant.

This plugin will be facilitating downloading the UDL, FunctionList definition, and AutoCompletion definitions from the UDL Collection, and themes from the Themes collection.

I am not a GUI designer, and my first idea for the interface isn’t always the best for most users, so I’d like to as a UI/UX opinion question of the readers here:

If the plugin has a dialog which will enable you to download a file with a DOWNLOAD button, but the user might want to do more than one dialog in a row (for example, if you want to grab a UDL file and then its FL), would you prefer:

After hitting DOWNLOAD for the first file, the dialog closes itself, so you have to re-run the Plugin command to get the next file
After hitting DOWNLOAD for the first file, when it’s done, it pops up a MessageBox to inform you it’s done, and you can go immediately get another file from the same dialog
After hitting DOWNLOAD for the first file, when it’s done, it changes a status bar on that dialog to indicate that it’s complete
Other ideas (the less complicated, the better)

I was originally planning on #2, but am starting to wonder if #3 is better. #1 was added to the options for completeness – though if that’s your preference, I’ll probably need an example of how to initialize/create a dialog once, but then hide it instead of closing it so that it can be reshown without being re-created. And I added #4 in case you want to make an alternative suggestion, even though I don’t guarantee that I’ll be able to implement the idea if it’s much more complicated than the current GUI design.

alpha testing

For those interested in alpha testing, the copy at https://github.com/pryrt/NppPlugin-CollectionInterface should now have all features implemented, though it definitely needs error handling improvements (right now, it will throw uncaught exceptions)

Coises

@PeterJones said in Need help with getting started using C++ Plugin Template:

If the plugin has a dialog which will enable you to download a file with a DOWNLOAD button, but the user might want to do more than one dialog in a row (for example, if you want to grab a UDL file and then its FL)

Consider using a List Box or a List View instead of a Combo Box. If you make it multi-selection, the user can highlight everything wanted at once and then click a button to download and relaunch. (That would be similar to the Plugins Admin… though I would not recommend putting the Install button at the top!)

Drop-downs can be annoying when you’re trying to select from a long list. They save space, but when there’s nothing much else in the dialog, you could display enough items at once in a List Box to make it easier for a user to scroll through, even if you make it single selection.

I’m pretty sure List Box is no more complex to use than Combo Box (aside from processing multiple selections, if you allow that). I don’t recall using a List View, but it does look like a bit more work.

Lycan Thrope

@PeterJones ,
This is kind of unfair, as you’ve already seen my clunky interface for the dBASE UDL installer. :-)

That aside, considering that, like the dBASE UDL, it’s really considered a package if you have all those files for the same language so it would make sense that the user should just pick the UDL they want to download, and your plugin would pick all the files needed for that package. This, of course, would be dependent on your application being aware of the files needed for it…and my guess is that since you’re trying to set it up to pull from the UDL repository, it would make sense that the repository have some kind of mechanism for the plugin to be able to read that mechanism’s connection of the different files for that language and be able to use that to collect all the relevant files for download at once.

Just my input, as it would seem to really simplify the process of getting UDL languages installed into Notepad++, so folks like me wouldn’t have to write their own installers to get the right files into the right directories. This is especially important if you have more than just a UDL definition, and also create the other files (functionList, autoCompletion, light and dark modes), because the problem is that they are all named the same, and hence, the need to have an installer.

I’ll try your plugin and see if I can help or not.

Edit:
If you’d like, I can send you my code that I used for the dBASE UDL installer, so you can see what I had to do to first identify if there is a standard system directory to install to, if there is no standard directory at which point they’d need to point to where the portable directory is, and if there is a cloud directory for either version. It’s in the dBASE language, but it’s a fairly easy language to read, to figure it out.

PeterJones

@Coises ,

Consider using a List Box

I will keep the Category as a dropdown (since there are only 4), but yeah, it makes sense to make the file list a List Box.

@Lycan-Thrope,

it would make sense that the repository have some kind of mechanism for the plugin to be able to read that mechanism’s connection of the different files

Yeah, there’s the JSON which has the information for 3 of the 4 file types (because Themes are a separate repo and not attached to the UDL). So it should be doable to automatically download all the appropriate files for a UDL (though I might make that be an option, because someone might want to just grab the updated UDL, without overwriting their previously-customized FunctionList, for example).

If you’d like, I can send you my code that I used for the dBASE UDL installer, so you can see what I had to do to first identify if there is a standard system directory to install to, if there is no standard directory at which point they’d need to point to where the portable directory is, and if there is a cloud directory for either version. It’s in the dBASE language, but it’s a fairly easy language to read, to figure it out.

I don’t see a reason for that, for me. NPPM_GETNPPDIRECTORY tells you where notepad++.exe is for the current instance, which is the only parent directory for autoCompletion\. And NPPM_GETPLUGINSCONFIGDIR, which tells you where Notepad++ Plugins\Config is, which is relative to %AppData% for standard, relative to notepad++.exe for local, and should* be relative to CloudDirectory or -settingsDir if one of those options is chosen.

Your installer needs the more complicated code, because you are running outside of Notepad++ environment, but the plugin should have access to all the information it needs to put the files in the right location.