Bug: improperly cloned expandable object

[bltdavid]

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

It's a fallacy only if you design it as a fallacy.

None of my expandable classes have a free form string property.

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?

Welcome to the hell known as comma separated values.

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)

Well, yep. That's one reason my expandable classes don't include strings.

If yours do, well, then you'll have to solve it.

You could try some kind of encoding, like URL encoding, for example. That would effectively remove the commas from your free-form string property, so that split() wouldn't get confused.

[ETFVoyageur]

I think the limitation on no strings is excessive. For example, one of mine has a "Comment" field. That must be a string.

[bltdavid]

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?

Not sure what you're asking.

[XmlIgnore()] tells the Xml serializer to skip that property. That's all.

That's why you need 2 properties, one for the property grid only, and one for the Xml serializer only.

[Edit: Oh, now I see what you mean. The answer is yes. The serialized string in the non-browsable property must account for whatever is necessary in order to recreate the object later -- so, sure, if recursion is needed to do that, so be it, the whole design is your choice.)

[ETFVoyageur]

By the way, for the record, the issue has nothing to do with nested properties, other than that they generate serialization strings.

The entire issue is with having string values at all, including simple string properties.

[bltdavid]

I think the limitation on no strings is excessive. For example, one of mine has a "Comment" field. That must be a string.

Well, sure, if you need a string, then you need a string. Turns out I never really did.

If I used a string I would encode the string property before adding to the comma separated serialized string.

That way, the de-serializer (using split) would not be confused by extraneous commas.

[bltdavid]

If I used a string I would encode the string property before adding to the comma separated serialized string.

https://en.wikipedia.org/wiki/Percent-encoding

https://www.google.com/search?q=c%23+urlencode

[ETFVoyageur]

That way, the de-serializer (using split) would not be confused by extraneous commas.

Why not? It will split on all commas in the string and you do not know how many were in the string. That's fine for a single string -- just put it last and concatenate all beyond the fixed values. But that breaks if you have two strings -- you don't know what to concatenate into each.

What am I missing?

[bltdavid]

Why not? It will split on all commas in the string and you do not know how many were in the string. That's fine for a single string -- just put it last and concatenate all beyond the fixed values. But that breaks if you have two strings -- you don't know what to concatenate into each.

What am I missing?

Using URL encoding, the resulting string has no commas.

Each comma character ',' is replaced by the 3 character string "%2C".

So, when building your serialized string, you are now free to use a comma as delimiter for split.

You're free to use a comma because you're guaranteed that the individual URL encoded string properties will not contain any comma characters themselves.

[ETFVoyageur]

I did not realize you meant URL encoded. I'm looking in to that, or a near variant, right now. I think that may be the best robust solution. Should be easy to sue once I get it set up.

[bltdavid]

I did not realize you meant URL encoded.

Was my comment at the bottom of post #46 not sufficient?

No matter, sounds like you'll have a full solution shortly.

Excellent.

[ETFVoyageur]

Thanks to Brett for his patience and help, and to bltdavid for his helpful comments.

Here's a summary:

• The bug was mine -- I had a complex property (an expandable property) and I had not written serialize/deserialize code for it. As a result I was getting NT default behavior, which did not work for this property.
• Getting a good serialization string methodology was a bit of a trick. I ended up taking the advice in this thread and encoding it. There was one issue -- this software has an expandable property, with a font picker child that in turn has a brush child. That makes complex objects 3 layers deep. Because of that the usual solution -- use the URL encoding -- was a non-starter. I ended up writing my own encode and decode static functions that can handle any amount of nesting. Not very difficult, and I'd recommend that to anyone in this situation.

The situation for complex objects is, as far as I can see:

• It it has only simple children don't worry about it. The default handling will be fine. This appears to be the case with SimpleFont as evidenced by not needed to pair a SimpleFont property with a serializer for it.
• If it has complex children, or if it has other reasons the default process is not good enough (e.g. data other than public Xml-available properties that needs to be handled) then you need to write serialize / deserialize code and any user of the property needs to handle it in the spirit of Brush or Color.
• It is easy to set up the general case -- recursive descent -- just call each child to serialize itself and encode all string values. Going the other way decode all string values and have each child deserialize itself.

Nothing about this was very difficult, but it did take a bit of thinking and some research to get it right. I believe it would be a fine topic for an NT example and/or tutorial. Brett, please pass that suggestion along.

I think that about covers it.

--EV