Finding the method an attribute is assigned to

  • Thread starter Thread starter Jason Bell
  • Start date Start date
J

Jason Bell

Give the following custom attribute:

[AttributeUsage(AttributeTargets.Method, AllowMultiple = false)]
public class WidgetEventAttribute : System.Attribute
{
protected Cegui.EventHandler mEventHandler = null;

public WidgetEventAttribute( string widgetname, string
eventname )
{
mEventHandler = new Cegui.EventHandler();
mEventHandler.Subscribe(
WindowManager.Instance.getWindow(widgetname), eventname );
}

public WidgetEventAttribute( Cegui.Window window, string
eventname )
{
mEventHandler = new Cegui.EventHandler();
mEventHandler.Subscribe( window, eventname );
}
}

That's used in the following way:


[WidgetEvent(this, Cegui.PushButton.EventClicked)]
protected bool HandleClicked()
{
Console.WriteLine("Oh ye of little faith!");
return true;
}

How would I know what method the particular attribute is assigned to?
WidgetEventAttribute is intended to create a delegate to the function
it's assigned to, and marshal that delegate as a function pointer to an
unmanaged library for a callback.

I've seen lots of examples where one reflects to find all methods, then
gets a list of attributes assigned to it. I'd like to do the opposite:
from within the a particular instance of WidgetEventAttribute, find what
method it's assigned to.

Before anyone asks, I have my reasons for doing it this way, largely due
to the weird way this library handles events.
 
Jason,
I've seen lots of examples where one reflects to find all methods, then
gets a list of attributes assigned to it. I'd like to do the opposite:
from within the a particular instance of WidgetEventAttribute, find what
method it's assigned to.

There's no built in way to retrieve that information. If the attribute
instance must know that, the code that retrieves the attribute
instance has to call a method or set a property to provide the
matching MethodInfo object.


Mattias
 
I've seen lots of examples where one reflects to find all methods, then
gets a list of attributes assigned to it. I'd like to do the opposite:
from within the a particular instance of WidgetEventAttribute, find what
method it's assigned to.

I don't believe there's any way of doing that. I don't think there's
even any guarantee that you get one instance of the attribute per time
it's referenced. For instance, it would make sense for the CLI to just
create one instance of the ThreadStaticAttribute and use that
everywhere it's applied.
 
Thanks for the input.

What I don't get, is how does the DllImport attribute work then? Surely it
must have to act on the function it's assigned to in some manner.
 
Jason Bell said:
Thanks for the input.

What I don't get, is how does the DllImport attribute work then? Surely it
must have to act on the function it's assigned to in some manner.

That's an attribute the CLR has special knowledge of, so it can do
extra things with it at load time.
 
Jon Skeet said:
I don't think there's
even any guarantee that you get one instance of the attribute per time
it's referenced.

No guarantee, perhaps, but that's the effect. If an attribute has
writable properties and you change the properties on an attribute
instance, you'll get the compiled-in values next time you retrieve
that attribute with GetCustomAttributes.
For instance, it would make sense for the CLI to just
create one instance of the ThreadStaticAttribute and use that
everywhere it's applied.

I know what you mean, but this is a bad example, imho - it would make
sense for the CLI to NEVER create a ThreadStaticAttribute instance,
but just look for it in the metadata when loading a type.
 
Jason said:
What I don't get, is how does the DllImport attribute work then? Surely it
must have to act on the function it's assigned to in some manner.

It's easy to go from method to attribute ....
 
Jon Shemitz said:
No guarantee, perhaps, but that's the effect. If an attribute has
writable properties and you change the properties on an attribute
instance, you'll get the compiled-in values next time you retrieve
that attribute with GetCustomAttributes.

Well, that's the current behaviour - but as I say, I don't believe
that's guaranteed. Now, if it's not guaranteed, it would be valid to
create a CLI implementation which didn't do that. If there were some
method specified to go from attribute to what it was applied to, there
would be no valid way to implement it in such a CLI implementation.
I know what you mean, but this is a bad example, imho - it would make
sense for the CLI to NEVER create a ThreadStaticAttribute instance,
but just look for it in the metadata when loading a type.

Except, of course, that you have to be able to retrieve *an* instance
of ThreadStaticAttribute if you ask for the custom attributes for the
field.
 
Hi Jason,

You posted this on another group and i replied that you shold try the
StackTrace. I was interested enough to give it a go and Stack trace
does work. Not sure if it will be any more efficient but you can give
it a go. From within you Attribute ctor try this:

System.Diagnostics.StackTrace t = new
System.Diagnostics.StackTrace();
Console.WriteLine(t.ToString());

Just my 2 pence,
Jan
 
Back
Top