Bug: improperly cloned expandable object

[bltdavid]

As Brett pointed out, NT does things in the context of the indicator. If they would also deserialize in that context, as I suggested, then the problem would disappear. Why not just do that -- very consistent with NT philosophy?

NT engineers use standard .NET routines for serialization & deserialization, probably because they saw no need to reinvent the wheel.

But, as a consequence, it becomes the indicator programmer's responsibility to add any extra code, as necessary, to handle any complex and/or dynamic properties that need special consideration.

As is, the way they are doing it, at just which point would you suggest that the indicator has the opportunity to fix things (and how would it know it is supposed to do that)?

You'll know because you will have coded it that way, using a 2nd nonbrowsable property.

For example, I wrote an expandable property class (in NT7) named TradeTime, and it serializes properly because I coded special routines to make that happen.

        private TradeTime TradeHours  = new TradeTime();

        [XmlIgnore()]
        [GridCategory("Time Management")]
        [Gui.Design.DisplayName("TradeHours")]
        public TradeTime xpTradeHours
        {
            get { return TradeHours; }
            set { TradeHours = value; }
        }

        [Browsable(false)]
        public string gsTradeHours
        {
            get { return TradeTime.SerializeToString(TradeHours); }
            set { TradeHours = TradeTime.SerializeFromString(value, XmlTimeZone); }
        }

See how the "gsTradeHours" property is designed specifically to handle all the chores related to serialization?

I added the static methods "SerializeToString/SerializeFromString" to the TradeTime class precisely to handle the conversion to/from a serialized string.

If your expandable class has an property that needs special fix-up, you can do that in the second property's set() method (eg, see my "gsTradeHours") -- it is that set() method that converts from the stored string back to an object of the expandable class.

[ETFVoyageur]

n/a -- I'm thinking about this one.

[ETFVoyageur]

On reflection, I may have a reasonable way. I'm thinking of handling it analogously to what you need to do for Color.

[bltdavid]

On reflection, I may have a reasonable way. I'm thinking of handling it analogously to what you need to do for Color.

Exactly! Yes!

[bltdavid]

Open up your .xml template file created by NT8 -- do you see all your indicator properties in there?

Is NT8 correctly serializing your BarNumbering and SimpleFont properties to that .xml template file?

As you move forward with using the serialization model used by Color properties, use the above steps to inspect/prove that your custom serialization property is working.

[ETFVoyageur]

I am happy to report good progress -- the basic idea works, but there is still an issue I do not yet have a good answer for.

The problem is what to generate for a serialization string. That string is central to the way NT expects things to operate. I don't know how to handle even the simple case in a robust manner. Suppose one of the things I need to serialize is a string -- that string can contain anything, so what am I to use for a separator in my own string such that deserialization will not get confused by finding the same thing in the serialized string property value?

To take the issue one step further, consider the case of a nested complex property. The only robust way to serialize that is to ask it for its serialization string. The problem is that it may well be using the same separator convention I am, once again resulting in confusion when deserializing. I don't suppose there is any library support for this, is there?

Surely I am not the first person to be concerned about this. What is the right way to construct a robust serialization string? The simplistic documented suggestion of just using some character as a separator obviously fails in the above cases.

Another question -- an I use any arbitrary character in the serialization string? For example, what if I used 8-bit control characters as my separators? The all I would need to worry about is that each complex object uses a different one.

[NinjaTrader_Brett]

One simple options I'm thinking off top of my head, though lots of ways to skin the cat. See my psuedo code below.

E.g. Imagine if datetime didn't serialize.

XMLIgnore()
Public DateTime MyTime;

[Browsable(False)]
Public int MyDateTimeSerialization_hours
{
set MyTime.Hour = value;
}

[Browsable(False)
Public int MyDateTimeSerialization_seconds
{
set MyTime.seconds= value;
}

[Browsable(False)
Public int MyDateTimeSerialization_minutes
{
set MyTime.minutes= value;
}

[ETFVoyageur]

Sorry, but I do not see how that answers my question about the best way to robustly construct a serialization string for an expandable object in the general case.

[NinjaTrader_Brett]

I've always been answering and talking in technical generics. I don't have a specific answer for your case other then I'd avoid mashing a huge string together if I could help it, thus my reply.

[ETFVoyageur]

OK -- does anyone else have a suggestion?

[ETFVoyageur]

I've always been answering and talking in technical generics. I don't have a specific answer for your case other then I'd avoid mashing a huge string together if I could help it, thus my reply.

The problem is that you cannot help it -- an object with properties, some of which may themselves be complex, will necessarily generate a non-trivial string. In general the string is generated by recursive descent.

Furthermore, even in the trivial case where you have only primitive properties a string may contain anything, making deserializtion a problem.

[ETFVoyageur]

It occurs to me that I could be making a bad assumption.

I have been assuming that if I mark my expandable object with [XmlIgnore], my serialization string must account for all of its children, recursively if appropriate. Is that true?

[bltdavid]

In my case, I made the static TradeTime.SerializeToString() method create one simple aggregate string with all properties delimited by a comma, then I added outer parentheses for the hell of it.

Conversely, the static TradeTime.SerializeFromString() method recognizes this string, use split to break up the string, and then uses each positional substring to re-populate the corresponding property.

As far as control characters, I have no idea. You'll have to experiment.

[ETFVoyageur]

I actually coded what you suggest, but then realized the fallacy.

Consider the case where one of the properties you need to serialize is a string. How well will your Split() call work when that string has a comma in it?

The simple solution is fine for all cases of primitive types other than string. It fails for any string-valued properties -- both string itself and any complex child (which will provide its own string)

[bltdavid]

The problem is that you cannot help it -- an object with properties, some of which may themselves be complex, will necessarily generate a non-trivial string. In general the string is generated by recursive descent.

Furthermore, even in the trivial case where you have only primitive properties a string may contain anything, making deserializtion a problem.

Well, as the programmer of the complex expandable class, that itself contains properties of other complex expandable classes, you are now faced with a new mission of designing how the class will serialize itself. This consideration should have probably come a lot sooner in your design ... but whatever.

I suspect there are few rules here, you have a lot of freedom to do whatever you think is best to produce correct results.

If you want to enjoy nested expandable properties on the GUI side, prepare to spend some extra time and pain on the serialization side.

In my case, I decided to punt: the GUI side is not worth the painful serialization hoops I saw on my horizon, so I don't use nested expandable properties. Too much work for too little real payback.

But your "nested" needs look to be different. So, enjoy, experiment, have fun.

Seriously, the entire design is up to you. Have fun, and good luck.

PS: Last I almost did this, I was seriously considering JSON to produce the serialized string. The JSON string would get stored to the Xml file and then parsed back into the expandable class -- JSON provides a serialize/de-serialize model.