Store array in options using DialogPage
Asked Answered
F

1

8

Assume that I need to store any array in the extension just freshly created from the template.

I just created new VSIX project, added VSPackage to it, then added option page grid (DialogPage). Then I followed instructions from answers to a similar question: DialogPage - string array not persisted.

And, for demonstration purposes, let's also add int[] array and plain int with custom type converter.

// [standard attributes]
[ProvideOptionPage(typeof(OptionPageGrid),
"My Category", "My Grid Page", 0, 0, true)]
public sealed class FooBarVSPackage : Package
{
    // standard code
}

public class OptionPageGrid : DialogPage
{
    // [typical attributes]
    [TypeConverter(typeof(StringArrayConverter))]
    public string[] Foos
    { get; set; }

    // [typical attributes]
    [TypeConverter(typeof(CustomIntConverter))]
    public int Bar
    { get; set; }

    // [typical attributes]
    [TypeConverter(typeof(IntArrayConverter))]
    public int[] Bazes
    { get; set; }
}

class StringArrayConverter : TypeConverter
{
    // exact copy of code from similar question/answer mentioned above
}

public class IntArrayConverter : TypeConverter
{
    private const string delimiter = "#@#";

    // CanConvertFrom, ConvertTo, etc. overridden in similar fashion
}

public class CustomIntConverter : TypeConverter
{
    // CanConvertFrom() overridden
    // CanConvertTo() overridden

    public override object ConvertFrom(ITypeDescriptorContext context, CultureInfo culture, object value)
    {
        var v = value as string;
        return int.Parse(v.TrimStart('*'));
    }

    public override object ConvertTo(ITypeDescriptorContext context, CultureInfo culture, object value, Type destinationType)
    {
        var v = (int)value;
        return v.ToString().PadLeft(25, '*');
    }
}

When I edit those options, I can see that the converter really works: Type Converter really works

But after I reopen it, two of the values gone! Only plain int persisted: Array values are lost, but plain int persisted

There is also one strange thing: how and when TypeConverter methods are called. CanConvertTo() is never called during the whole session. CanConvertFrom() and ConvertTo() are called often and more or less in expected fashion. And ConvertFrom() is called only when the string representation of the option is edited directly, i.e. it doesn't participate in loading/saving options at all!

I'm not sure, but it feels a bit like int option is stored as int and turned from/into string only in options GUI, while array options just silently fail trying to do the same.

P.S.: If you want to directly play with the example personally, here is a GitHub repo with the example project in question: FooBarVSIXProject

Froe answered 23/9, 2015 at 23:23 Comment(0)
F
8

After spending several hours trying to fix broken “easy to use” mechanism (either itself is broken or its documentation), I realized that instead of wasting time, I should have descend just one abstraction layer down and do exactly what I wanted DialogPage mechanism do automatically.

One would expect that DialogPage should save/load the string representation (obtained through type converter) into/from User Settings Store (or something like that) when its SaveSettingsToStorage() and LoadSettingsFromStorage() are called. Since it refuses to do so and those methods are virtual, we can do exactly that ourselves:

public class OptionPageGrid : DialogPage
{
    const string collectionName = "FooBarVSIX";

    [Category("General")]
    [DisplayName("Foos")]
    [Description("Bla Foo Bla")]
    // note that TypeConverter attribute is removed,
    // because it's not relevant anymore
    public string[] Foos
    { get; set; }

    // Bar and Bazes properties missed out to make this example shorter

    public override void SaveSettingsToStorage()
    {
        base.SaveSettingsToStorage();

        var settingsManager = new ShellSettingsManager(ServiceProvider.GlobalProvider);
        var userSettingsStore = settingsManager.GetWritableSettingsStore(SettingsScope.UserSettings);

        if (!userSettingsStore.CollectionExists(collectionName))
            userSettingsStore.CreateCollection(collectionName);

        var converter = new StringArrayConverter();
        userSettingsStore.SetString(
            collectionName,
            nameof(Foos),
            converter.ConvertTo(this.Foos, typeof(string)) as string);
        // save Bazes in similar way
    }

    public override void LoadSettingsFromStorage()
    {
        base.LoadSettingsFromStorage();

        var settingsManager = new ShellSettingsManager(ServiceProvider.GlobalProvider);
        var userSettingsStore = settingsManager.GetWritableSettingsStore(SettingsScope.UserSettings);

        if (!userSettingsStore.PropertyExists(collectionName, nameof(Foos)))
            return;

        var converter = new StringArrayConverter();
        this.Foos = converter.ConvertFrom(
            userSettingsStore.GetString(collectionName, nameof(Foos))) as string[];
        // load Bazes in similar way
    }
}

Now, of course, if you do it this way, you don't have to write and use TypeConverter, actually. You can just embed serialization logic right into those methods, or anywhere.

Also, you can serialize your data just right into binary format and use SetMemoryStream() to save it.

Froe answered 27/9, 2015 at 13:9 Comment(3)
This is a bug in VS 2015. MS substantially changed the logic in DialogPage.LoadSettingsFromStorage and SaveSettingsToStorage between VS 2013 and VS 2015, and they broke LoadSettingsFromStorage for properties that use TypeConverters. I've reported this via VS 2015's "Report a problem" dialog and via Connect, so maybe they'll fix it eventually. In the meantime, I also had to workaround it with overrides like you did. Note: TypeConverters are still useful for editing values in the PropertyGrid. Also, the MS bug is in DialogPage.SetPropertyValue, which just calls Convert.ChangeType now.Samul
@BillMenees sorry for resurrecting this ancient topic, but do you know if this VS bug ever get resolved? Can you provide a link to the Connect issue?Scolecite
@Scolecite It was fixed in VS 2017. Microsoft has retired the Connect site, but here's a (broken) link to the old Connect issue: connect.microsoft.com/VisualStudio/feedback/details/2627657.Samul

© 2022 - 2024 — McMap. All rights reserved.