Have noticed in other threads that watchlists can be made from a XML template and just altering a comma delimited list of symbols within <DSString> & </DSString>

The template for my Datasets created from 'ASCII Files' provider seem quite complex compared to some forum samples, ie:

CODE:
Please log in to see this code.

What would be the crucial detail above to maintain from DSString in making a template for creating watchlists via a script?
Thanks

QUOTE:
creating watchlists via a script?

First things first, if you're after mixing the data from DataSets which belong to different static data providers, better forget about it. Also you won't be able to mix two quite different ASCII DataSets together this way. Otherwise read on.

QUOTE:
Have noticed in other threads that watchlists can be made from a XML template and just altering a comma delimited list of symbols within <DSString> & </DSString>

Incorrect, or only partially true. What you saw in other thread is an example of creating a Fidelity DataSet. Which is the simplest kind of DataSet XML file you could see. Other data providers might be required to keep much more serialized data in there - like ASCII.

QUOTE:
What would be the crucial detail above to maintain from DSString in making a template for creating watchlists via a script?

As Cone already clearly said earlier, each DSString is unique: every static data provider has its own, independent way of serializing/deserializing DataSet configuration in a DSString. Consequently, preserving the entire DSString is an absolute must.

Keep in mind what the FAQ states on restarting WLD6 here: Is it possible to make actions on DataSets programmatically?.

Thanks Eugene

yes had already seen the link.

Guess I'll just have to give up on making watchlists (and wonder just why Fidelity is playing this v important utility out the way they are?).

Appreciate your responding.

Dynamic WatchList Support (aka creation of DataSets in WealthScript) is a registered feature request that has been around for years. Unfortunately, deferred.

Undoubtedly it's important but based on the number of requests, I'd prefer if Fidelity switched to .NET 4.0 (.NET 2.0 is more than 5 years old!), added support for .NET 4 assemblies, and brought multi-core CPU usage in the Optimizer (for parallel optimizations) in the first place.