Context: NT8 Beta 6
If the value of a property which should be serializable has a value specifying a custom bar type, it cannot be deserialized. So when attempting to load a template or workspace which has an indicator or strategy with such a property, the indicator is removed from the chart, with no warming except a log entry (most users would have no idea what was wrong.)
I've attached a log file showing the log entry.
One solution is to define an associated serialization property, and attach the XmlIgnore attribute to the property itself.
However, this either needs to be much better documented, or some other solution for custom bar types needs to be implemented. Perhaps one of the following:
1) Use strings (names) to identify bar types, not enumeration constants. This would have other major benefits. Some examples: Better avoidance of identity key clashes between multiple providers of custom bar types; making it easier to specify custom bar types as the value of an indicator or strategy property.
2) Use integers to identify bar types, not an enumeration type; provide a function which maps between integer codes and bar type names, including those for custom bar types; and provide a way to select defined bar types by name from a list in property dialogs.
3) Globally handle the serialization of properties of type BarsPeriodType specially, so that custom coders don't have to be concerned with the issue.
If the value of a property which should be serializable has a value specifying a custom bar type, it cannot be deserialized. So when attempting to load a template or workspace which has an indicator or strategy with such a property, the indicator is removed from the chart, with no warming except a log entry (most users would have no idea what was wrong.)
I've attached a log file showing the log entry.
One solution is to define an associated serialization property, and attach the XmlIgnore attribute to the property itself.
However, this either needs to be much better documented, or some other solution for custom bar types needs to be implemented. Perhaps one of the following:
1) Use strings (names) to identify bar types, not enumeration constants. This would have other major benefits. Some examples: Better avoidance of identity key clashes between multiple providers of custom bar types; making it easier to specify custom bar types as the value of an indicator or strategy property.
2) Use integers to identify bar types, not an enumeration type; provide a function which maps between integer codes and bar type names, including those for custom bar types; and provide a way to select defined bar types by name from a list in property dialogs.
3) Globally handle the serialization of properties of type BarsPeriodType specially, so that custom coders don't have to be concerned with the issue.
Comment