Compartir a través de

Req9: allow CObj in constants and attributes

  • Artículo

[This post is part of a series, "wish-list for future versions of VB"]

 

IDEA: Allow a CObj in constants and attributes. Currently it's not allowed, for instance, to write Const x As Object = CObj("hello") or to pass CObj(1) into an attribute, Both should be allowed.

This request comes from a single scenario, the ComponentModel.DefaultValue attribute. This is used when creating custom controls. You decorate each of your properties with this attribute so as to tell the IDE what is the default value of the property. In the IDE's property pane, non-default values are shown in bold; and properties are only stored in the .Designer.vb file if they're non-default. Mostly this attribute is fine from VB but it's awkward in one case, that of Enums.

The following code compiles okay, but the IDE refuses to recognize this as a default value for an enum. That's because it picks the DefaultValue(Integer) overload, but the IDE only accepts the DefaultValue(Object) overload as meaningful for an enum

<ComponentModel.DefaultValue(ConsoleColor.Blue)>

Property col As ConsoleColor

Instead you're currently forced to use one of two workarounds. You can either pass the default as a string (which is bad because it lacks type-safety):

    <ComponentModel.DefaultValue(GetType(ConsoleColor), "Blue")>

    Property col As ConsoleColor

Or to regain type safety you have to define your own attribute:

    <EnumDefaultValue(ConsoleColor.Blue)>

    Property col As ConsoleColor

    Public Class EnumDefaultValueAttribute : Inherits ComponentModel.DefaultValueAttribute

        Public Sub New(ByVal value As Object)

            MyBase.New(value.GetType, value.ToString)

        End Sub

    End Class

It would be much easier if we could simply write this:

    <ComponentModel.DefaultValue(CObj(ConsoleColor.Blue))>

    Property col As ConsoleColor

 

Provisional evaluation from VB team: On the one hand, this counts as a bug in the IDE's treatment of DefaultValueAttribute. There should never be any cases where picking an "Object" overload is different from picking a more specific overload. Imagine the confusion if Console.WriteLine(Object) behaved differently from Console.WriteLine(Integer).

On the other hand, it's an unnecessary limitation in VB that it doesn't allow CObj in attributes.

 

What do you think? If the DefaultValueAttribute were fixed up so that CObj weren't needed for it, have you encountered any other scenarios where you've needed CObj in a constant or attribute?

Comments

  • Anonymous
    February 15, 2010
    If you fix the IDE bug, I’ve never had a need for this anywhere else (although it is a bizarre and arbitrary limitation).

  • Anonymous
    February 18, 2010
    Yeah, this should be fixed in the IDE side.