How To Get Attributes From The "Current" Property???

[Bob Cohen \(106531\)]

I want to define some metadata using custom attributes to apply to
properties in various classes.

The properties return values that are classes themselves.

I want to retrieve the attribute information in the classes from which the
fields/properties are derived, but I can't figure out how to get them. I
seem to be stuck since the attributes are declared against the property, but
the information is returned from the base class; I don't see how to get "the
current" attribute information without knowing the specific name of the
property ahead of time.

i.e. Attribute.GetCustomAttribute() or Attribute.GetCustomAttributes() both
want to know the MemberInfo of the property first, but you can't get the
MemberInfo without knowing the name of the property. I don't know how to
get the name of the calling property from within its class. And
this.GetType().GetCustomAttributes() returns information about the base
type, not the calling property.

Here's a simple app that demonstrations what I'd like to accomplish:

using System;
using System.Windows.Forms;

namespace WindowsApplication1
{
public partial class Form1 : Form
{
public Form1()
{
InitializeComponent();
}

private DbIntField _xxx = new DbIntField();

[Test(true)]
public DbIntField xxx
{
get { return _xxx; }
}
}

[AttributeUsage(AttributeTargets.Property)]
public class TestAttribute : Attribute
{
public bool IsTestable = false;

public TestAttribute(bool IsTestable)
{
this.IsTestable = IsTestable;
}
}

public class DbIntField
{
public bool IsTestable
{
get
{
=== How to get to the test attribute without explicitly
specifying the string "xxx"???
}
}
}
}
Thanks,
Bob Cohen

[Marc Gravell]

Well, the instance of a DbIntField isn't techically associated with
any specific property, not least since the same reference could
theoretically be associated from several properties (either as
separate "real" properties, or as pass-thru facades). As such, perhaps
your best approach is to work with the property rather than the
instance. In particular, this scenario seems like it might fit a
simple ITypeDescriptorContext implementation (i.e. public static bool
IsTestable(ITypeDescriptorContext ctx), which would provide the
property (PropertyDescriptor) and the owing instance, which infer the
value (the DbIntField) - or the value could be passed in separately.
This approach will work very will if you are already using
PropertyDescriptor view-based (rather than model-based) code.

The only other viable route involves intentionally making each
DbIntField aware of its context, perhaps via a parameterised ctor.
This is unwieldy at best, but can be made to work.

Marc

[Bob Cohen \(106531\)]

OK, I'll look into this. Although at first blush neither approach is
"attractive" for the coding model that I'm using. I'm just surprised that
the chain of ownership for this instance of the DbIntField isn't available
somewhere.

Thanks,
Bob

"Marc Gravell" <ma**********@gmail.comwrote in message
news:11**********************@y18g2000prd.googlegr oups.com...

Well, the instance of a DbIntField isn't techically associated with
any specific property, not least since the same reference could
theoretically be associated from several properties (either as
separate "real" properties, or as pass-thru facades). As such, perhaps
your best approach is to work with the property rather than the
instance. In particular, this scenario seems like it might fit a
simple ITypeDescriptorContext implementation (i.e. public static bool
IsTestable(ITypeDescriptorContext ctx), which would provide the
property (PropertyDescriptor) and the owing instance, which infer the
value (the DbIntField) - or the value could be passed in separately.
This approach will work very will if you are already using
PropertyDescriptor view-based (rather than model-based) code.

The only other viable route involves intentionally making each
DbIntField aware of its context, perhaps via a parameterised ctor.
This is unwieldy at best, but can be made to work.

Marc

[Marc Gravell]

Again, see my point that in general the same (reference-type) object
could have multiple owners, without any precedence.

Marc