The node to be inserted is from a different document context

[imilne]

Right, time to get to the bottom of this bugger. I've seen this error with a couple of my plugins now, but seeing as they were all written in the same way that's hardly surprising

Here's the first block of code that runs when the System plugin saves its settings (after clicking ok in the Settings dialog):

Code:

string path = "/Settings/PluginSettings/System";

SettingsHelper sh = SettingsHelper.GetInstance();
XmlDocument doc = sh.GetBackingDocument();
XmlNode system = sh.GetSettingsNode(path);

// Clear the current <System> node (if it exists)
if (system != null)
   system.RemoveAll();
// Otherwise, create it
else
{
   system = doc.CreateElement("System");
   sh.GetSettingsNode("/Settings/PluginSettings").AppendChild(system);
}

//Now (re)fill it with data
system.AppendChild(doc.CreateElement("ConfirmShutdownMode"));
// More similar lines follow...
...

"System.ArgumentException: The node to be inserted is from a different document context", "at System.Xml.XmlNode.AppendChild(XmlNode newChild)" is thrown - very very rarely - when it hits that last line of code. Why?

If it was wrong, surely it would crap-out every time :confused:

Testing fixes is difficult because it's so rare. If I open/ok, open/ok, etc the Settings dialog enough times I can usually force it, but I'd love to get rid of it for good!

Iain

[psycik]

Maybe do a bit less combined operations so you can debug it better.


Oh was going to follow that up, but just realised, you're getting the backingdocument to a xmlDocument doc but then continuing to do stuff on the SettingsHelper.

Perhaps get teh document, and then do all the createelements and appends on the doc not the sh.

[mvallevand]

I never trusted config.xml as a source for my plugin's xml files. It is now being updated by NextPVR (TV Groups, online updates, and decoders come to mind) and with MVP and NMT's this could be multi-user, so I prefer distancing myself from it.

Martin

[imilne]

Perhaps get teh document, and then do all the createelements and appends on the doc not the sh.

Same object though aren't they? I always assumed SettingsHelper was just sub's collection of "helper" methods for dealing with the document. My reference to doc should be the same as the one in SettingsHelper.

@Martin: hmm, might be worth trying it externally just to see, but I do find it handy to put stuff there - it's one less thing for the user to worry about if the settings all stay together.

Iain

[Jaggy]

@Martin: hmm, might be worth trying it externally just to see, but I do find it handy to put stuff there - it's one less thing for the user to worry about if the settings all stay together. Iain

Before I comment I'm not actually in a "Pick on Iain" mode it's just there have been a few things you have posted over the last few days that I have disagreed with & this is another one.....

I "personally" prefer if the config file for a plugin is in the plugin's own directory, firstly I find them easier to find if I need to edit them, secondly if for whatever reason I decide/need to change the NextPVR config.xml all I need to do (after it generates a new clean one) is go into settings & enable the plugins whereas if they are also in the NextPVR config I have to reinstall & reconfigure them...... just my 2c worth.

[imilne]

Before I comment I'm not actually in a "Pick on Iain" mode it's just there have been a few things you have posted over the last few days that I have disagreed with & this is another one.....

Meow

I "personally" prefer if the config file for a plugin is in the plugin's own directory, firstly I find them easier to find if I need to edit them, secondly if for whatever reason I decide/need to change the NextPVR config.xml all I need to do (after it generates a new clean one) is go into settings & enable the plugins whereas if they are also in the NextPVR config I have to reinstall & reconfigure them...... just my 2c worth.

I can understand that. I'm not keen on having separate config files for every plugin, but I'll certainly give it a try because of this problem. Am I the only plugin developer storing settings this way?

Iain

[imilne]

Always difficult to tell with this sort of problem, but I've moved the settings to their own file and so far haven't seen the error again.

Iain

[bgowland]

I can actually see the advantage of plugins saving their data in the config.xml but I can also see problems with it.

I'm not sure if it was a particular version of gbpvr or npvr but I seem to remember some issues that devs had in the past which either meant their settings weren't being saved properly or worse, even corrupting the config.xml file itself (I may be wrong - the little grey cells are diminishing as time flies). I think that put a lot of devs off.

Personally I don't care either way as long as it works and as I keep 8 days of backups of all the essentials related to npvr (db, config.xml, logs, xmltv files etc) I can swap stuff back in place in a few minutes if anything goes wrong.