I need some help with planning for future user installs of a lexer plugin.
The plugin will have a config XML file, initially with just LexerStyles defined; later I plan to add some keywords to the Languages section. These changes will probably occur incrementally over several releases.
If I understand correctly, PluginManager will install XML and INI files to the proper Config directory when doing a plugin install or update, but presumably it will overwrite any existing XML or INI file with the same name. If the user has spent time customizing styles to their liking, those customizations need to be merged into the updated XML file.
My questions are ...
First, I will follow Dave Brotherstone's advice (from "Top 10 Hints for writing a Notepad++ plugin...")
and version the XML file. What is the best way to do that? I've thought of adding a "version=" attribute
to the Language and LexerType elements - is that going to break anything? Or is there a "best practice"
for doing this?
Second, how does a plugin detect that it is being updated? Where does the code go that will merge the
old Config with the updated Config? Does PluginManager have any support routines for this or is it
necessary to write something from scratch using the TinyXML library?
When that site talks about versioning, it means the DLL. The plugin manager does not look at the version of any other files.
You must detect when your plugin has been updated. I would recommend putting the "version=" attribute, or something similar, in your XML file. That way each time your plugin starts up it can look at what version created that XML file and determine if your plugin's version is newer than the XML "version" and take any steps necessary. Then any time you write out the XML file, put the current version in the attribute.
Also, about merging configs, again you must do this. What I've done in the past is hard-code default values for all the possible options, then read in the config. That way if the config file doesn't specify an option(which is probably because it was from an older version of the plugin), you know what to use as a default.
You could also have a default xml file (that you only read from) that is installed with your DLL. And if the user makes any changes, save a new copy (either a full copy or just what is different from the default). When your plugin is updated, it will have a new default xml file (because the plugin manager copied the new default xml), then merge in the older copy of the xml file.
Hope I didn't confuse you too much. :)
P.S. I've mostly mentioned XML files here but the same goes for INI or any other format.
Hi, & thanks for your reply.
I think I understand the mechanism. Let me rephrase it to make sure ...
Let's say the original installer uses a config file called PluginName_ref.xml.
Initially, PluginName.xml does not exist, so PluginName_ref.xml is just copied to PluginName.xml.
A happy user sees an update and uses plugin manager to install it.
Now, a new PluginName.dll and PluginName_ref.xml is installed.
PluginName_ref.xml's version is compared against the PluginName.xml in use.
If they are different then the changes are merged into PluginName.xml.
One last question. At what stage should this file manipulation take place?
Seems like I need to monitor some notification from NPP, to properly synchronize
with the startup sequence.
(I'll take a peek at DoxyIt to see how you do it)
Yes. That certainly is one way of doing it. The best place to check this is when you load in the config. I do mine when I get the NPPN_READY notification from N++. The full list of notifications and messages can be found here.
I'll state I've never messed with lexers, but I believe they are similar enough to plugins that all this still applies.
I'm sure you've found it by now but just in case, the DoxyIt source code is here. If you have any more questions feel free to ask.
Thanks for that. I'll take a look at configSave() and configLoad() in DoxyIt.
Maybe creating a backup on configSave() will be an easier approach.