locked
When is GetStandardValues called? RRS feed

  • Question

  • The following code implements a simple derived control with a public property called "MyProp". This property has a drop-down list with valid values:

    using System;

    using System.Collections.Generic;

    using System.Text;

    using System.Windows.Forms;

    using System.ComponentModel;

    using System.Collections;

    namespace DefaultValuesTest2 {

    public class MyTypeConv: TypeConverter {

    public override bool GetStandardValuesSupported(ITypeDescriptorContext context) {

    return true;

    }

    public override bool GetStandardValuesExclusive(ITypeDescriptorContext context) {

    return true;

    }

    public override StandardValuesCollection GetStandardValues(ITypeDescriptorContext context) {

    ArrayList list = new ArrayList(10);

    list.Add("Name1");

    list.Add("Name2");

    list.Add("Name3");

    return new StandardValuesCollection(list);

    }

    }

    public class DefaultValLabel: Label {

    private string _myProp;

    [TypeConverter(typeof(MyTypeConv))]

    public string MyProp {

    get { return _myProp; }

    set { _myProp = value; }

    }

    }

    }

    This code works fine, i.e. if I place a DefaultValLabel on a form, the property "MyProp" works as expected and shows a drop-down list with 3 entries.

    However, if I now change the implementation of GetStandardValues, e.g. add some new entries into the drop-down list, these new entries are NOT shown in the Visual Studio Designer. Rebuilding the application does not help. The only thing, which helps, is closing Visual Studio and restarting it.

    Am I doing something wrong in my code, or is the Visual Studio designer only calling GetStandardValues once and then caching the drop-down list?

    Monday, July 24, 2006 12:08 PM

Answers

  • Dear joeycalisay.

     

    You are right.

    I tried to change the code again, this time building the drop-down list like this:

    list.Add(context.Instance.GetType().Assembly.FullName);

    list.Add(context.Instance.GetType().Assembly.Location);

    It turned out, that the assembly has the following location:

    C:\Documents and Settings\username\Local settings\Application Data\Microsoft\VisualStudio\8.0\ProjectAssemblies\xxxxxxxx\Assemblyname.dll

    where xxxxxxxx is some random folder name. This must be the location, where VS caches assemblies.

     

    The next thing, I discovered: If I change the AssemblyVersion in the AssemblyInfo.cs file and build the assembly, then VS will use the new version of the assembly! I.e. any changes to the typeconverter code will appear immediately in the VS designer without restarting VS. Problem solved :-)

    Is it possible to get VS to increase the AssemblyVersion automatically on each build?

    /CRosendal

     

    Thursday, July 27, 2006 10:03 PM

All replies

  • I guess you may reference the ControlLibrary project in your main project. In this case, if you modify the code in ControlLibrary project, in have to re-reference the ControlLibrary project to apply your modification. Otherwise, visual studio will use the previous version of the project even though you have rebuilt your application.
    Wednesday, July 26, 2006 6:27 AM
  • No, actually the derived control is in the same project as the form, which I place the control on.

    Wednesday, July 26, 2006 7:48 AM
  • the assembly which VS might be using is somewhere cached.  i really prefer to have separate projects for control and the windows forms application.  this way, i also take advantage of debugging controls using two IDEs.

    have you tried closing all designer windows after a rebuild?  are you also rebuilding the windows forms project after the control build?
    Wednesday, July 26, 2006 10:50 AM
  • Normally, I would always put the controls into a different project, too.

    I just put the form and the control into the same project in this case, to see, if it made a difference.

    If I put the control and form into two different projects, the problem is the same.

    I can rebuild the whole solution or rebuild both projects independently - nothing helps.

    Closing all windows in VS doesn't help.

    Even closing the solution and reopening it, does not help.

    I really have to close Visual Studio and restart it, to get the new drop down list in the designer.

     

    Now, I have tried to change the implementation of GetStandardValues, building the list like this:

    list.Add(DateTime.Now.ToString());

    list.Add(DateTime.Now.ToString());

    list.Add(DateTime.Now.ToString());

     

    When using this implementation (after having restarted VS :-) ), I can see, that the content of the drop-down list is actually updated on each drop down. This shows, that GetStandardValues is actually called each time, i.e. the list itself is not cached - but it must be the code, that is cached by VS somehow???

     

     

    Wednesday, July 26, 2006 11:56 AM
  • ok then, VS caches the referenced assembly, you can check it out to see what version of control dll the windows app is using and where it is located by debugging the windows app with another ide instance and use the modals window to see the loaded assemblies and their corresponding paths.
    Thursday, July 27, 2006 4:59 AM
  • Dear joeycalisay.

     

    You are right.

    I tried to change the code again, this time building the drop-down list like this:

    list.Add(context.Instance.GetType().Assembly.FullName);

    list.Add(context.Instance.GetType().Assembly.Location);

    It turned out, that the assembly has the following location:

    C:\Documents and Settings\username\Local settings\Application Data\Microsoft\VisualStudio\8.0\ProjectAssemblies\xxxxxxxx\Assemblyname.dll

    where xxxxxxxx is some random folder name. This must be the location, where VS caches assemblies.

     

    The next thing, I discovered: If I change the AssemblyVersion in the AssemblyInfo.cs file and build the assembly, then VS will use the new version of the assembly! I.e. any changes to the typeconverter code will appear immediately in the VS designer without restarting VS. Problem solved :-)

    Is it possible to get VS to increase the AssemblyVersion automatically on each build?

    /CRosendal

     

    Thursday, July 27, 2006 10:03 PM
  • afaik if you set build and revision numbers to *, it autoincrements
    Friday, July 28, 2006 8:36 AM