When do type converters for expandable objects get run?

[ETFVoyageur]

I have a couple of expandable objects, and they seem to be working pretty well. I even made type converters for them, as all the documentation says a good little programmer should. I have put breakpoints in all four functions of each of them, and the breakpoints never get hit. What is going on?

CanConvertTo(), ConvertTo(), CanConvertFrom(), ConvertFrom()

The documentation also says that the string provided by ConvertTo() will be used in the PropertyGrid. That does not seem to be the case, which is fine with me. ToString() shows up in the property grid, meaning I can make the ConvertTo() easy to parse, without regard for GUI readability. I'm just puzzled why the documentation I have found on line says ConvertTo() will end up displayed by the PropertyGrid.

[koganam]

I have a couple of expandable objects, and they seem to be working pretty well. I even made type converters for them, as all the documentation says a good little programmer should. I have put breakpoints in all four functions of each of them, and the breakpoints never get hit. What is going on?

CanConvertTo(), ConvertTo(), CanConvertFrom(), ConvertFrom()

The documentation also says that the string provided by ConvertTo() will be used in the PropertyGrid. That does not seem to be the case, which is fine with me. ToString() shows up in the property grid, meaning I can make the ConvertTo() easy to parse, without regard for GUI readability. I'm just puzzled why the documentation I have found on line says ConvertTo() will end up displayed by the PropertyGrid.

How are you trying to trigger the breakpoints? What is the test scenario?

Hm. I always thought that ToString() controlled what got displayed in the PropertyGrid. Actually, I have never heard or seen otherwise.

[ETFVoyageur]

My experience agrees with you -- ToString() is what gets displayed, certain documentation notwithstanding.

As to triggering -- I just leave the breakpoints in there permanently. Bring up the Indicators dialog, add the indicator, Apply it, Save it, exit the program, etc. I can see serialization taking place -- property Get() is called when that happens. No converter routine ever gets called. Serialization is functionally successful -- I can exit and restart with the user choices intact.

(Other type converters do get called -- for example when using a string array property.)

[koganam]

My experience agrees with you -- ToString() is what gets displayed, certain documentation notwithstanding.

As to triggering -- I just leave the breakpoints in there permanently. Bring up the Indicators dialog, add the indicator, Apply it, Save it, exit the program, etc. I can see serialization taking place -- property Get() is called when that happens. No converter routine ever gets called. Serialization is functionally successful -- I can exit and restart with the user choices intact.

(Other type converters do get called -- for example when using a string array property.)

I notice that you load and exit. That would handle defaults. Try changing the parameter.

[ETFVoyageur]

I tried all sorts of things -- everything I could think of, including changing parameter values. The cases where I expected it to serialize I found it called the properties directly, so serialization was taking place. But they never called any type converter functions.

My opinion is that NT ignores the type converters for expandable classes -- or at least those functions I named. The type converters subclass from ExpandableObjectConverter, so they may be making use of other functions that provides.

That seems like a bug in general. It is not hurting me, but using the type converters would allow for serializing more information than the way NT is doing it now. Unless there is some problem I am not aware of (be careful what you wish for ...) I would urge them to use the type converters for serialization rather than winging it.

[bltdavid]

I would urge them to use the type converters for serialization rather than winging it.

Yeah, I don't do it that way. I made the expandable class itself responsible for serializing.

My experience is NT7 only, I've not ported these expandable properties to NT8 yet.

For example, I have an expandable property class called TradeTime (see attached screenshot) that neatly encapsulates start and stop time into an expandable property.

First I declare the backing store variable,

        private TradeTime TradeHours = new TradeTime();

then here is the property,

        [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); }
        }

I found it easier to design my expandable property classes to always provide two static methods SerializeToString() and SerializeFromString() that do all the work for serialization.

All my TypeConverter classes (such as TradeTimeConverter) are simply not involved in the serialization process.

Does any of that help?

[bltdavid]

A bit more info.

I define my TradeTime class like this,

[TypeConverter(typeof(TradeTimeConverter))]
public class TradeTime
{
....
}

My entire TradeTimeConverter class is below,

public class TradeTimeConverter : ExpandableObjectConverter
{
    public override bool CanConvertFrom(ITypeDescriptorContext context, Type SourceType)
    {
        if (SourceType == typeof(string))
            return true;
        return base.CanConvertFrom(context, SourceType);
    }

    public override object ConvertFrom(ITypeDescriptorContext context, CultureInfo culture, object value)
    {
        GridItem gridItem = context as GridItem;
        Object oldvalue = gridItem == null ? null : gridItem.Value;

        if (value is string)
            [COLOR=Red]return TradeTime.ConvertFromString((string)value, (TradeTime)oldvalue);[/COLOR]

        return base.ConvertFrom(context, culture, value);
    }

    public override bool CanConvertTo(ITypeDescriptorContext context, Type DestType)
    {
        if (DestType == typeof(string))
            return true;
        return base.CanConvertTo(context, DestType);
    }

    public override Object ConvertTo(ITypeDescriptorContext context, CultureInfo culture, Object value, Type DestType)
    {
        if (DestType == typeof(string))
            return value.ToString();
        return base.ConvertTo(context, culture, value, DestType);
    }
}

When I create a new expandable property class, the line in red is the only line of code that needs to change in the new class's customized TypeConverter class.

As you can guess, ConvertFromString is a static method that, just like the SerializeToString / SerializeFromString static methods in my previous post.

All code is for NT7.

[NinjaTrader_Matthew]

We are currently in the process of researching what is possible with our property grids and various converters, and will document what we can support. I am not in a position where I can make any comments which would be of any value to help, but I will make sure this use case is added to our research.

@ETFVoyageur, can you please link me to the documentation you were referring to so I can add this to our notes?

[ETFVoyageur]

We are currently in the process of researching what is possible with our property grids and various converters, and will document what we can support. I am not in a position where I can make any comments which would be of any value to help, but I will make sure this use case is added to our research.

@ETFVoyageur, can you please link me to the documentation you were referring to so I can add this to our notes?

I hope you end up supporting at least those that were supported in V7, such as enum converters.

Here is a reasonably official reference: MSDN: Getting the Most Out of the .NET Framework PropertyGrid Control. Check about 3/4 of the way down the page, after Figure 5, where they are discussing adding spell check options. Note the following text, which clearly says that the ConvertTo string will be displayed in the property grid. (My added italic underline, for emphasis)

Override the ConvertTo method and ensure that the destinationType parameter is a String and that the value is the same type as the class that uses this type converter (the SpellingOptions class in your example). If either case is false, return the value of the base class ConvertTo method; otherwise return a string representation of the value object. The string representation needs to separate each property of your class with a unique delimiter. Since the whole string will be displayed in the PropertyGrid you will want to choose a delimiter that doesn't detract from the readability; commas usually work well.

That said, I personally do not like that. There is no good reason to believe that the optimal string for serialization is a good, or even acceptable, string for the GUI. If I had my way ToString() would continue to be used in the GUI, while the ConvertTo string would be used for serialization.