Reply to: Determining calling type in a base class

[ASB]

Tell me about it. Reflection is one of those things that is really useful to know, but something you'll only use once or twice a year!!!

So I take it that you've got a static method in the concrete class that inherits from the base, and for some reason the stack trace isn't returning any frames?

Or have you overridden the base class's method?

If I recall correctly (and I might not)

- All the method were static
- A derived class was being invoked as a result of a call from a static method method on the derived class
- All I really wanted to find out was the class that was calling.

But I must admit to having rather lost the will to persue it any further.

[Cowboy Bob]

I'll rephrase my original comment to, one of those things you only do something interesting in once or twice a year!!!!

[Weltchy]

I'll rephrase my original comment to, one of those things you only do something interesting in once or twice a year!!!!

[Cowboy Bob]

Tell me about it. Reflection is one of those things that is really useful to know, but something you'll only use once or twice a year!!!

Butting into the conversation, but if that's the case how do you implement an AbstractFactory in the .NET world? Surely you make use of one of those much more than once a year, it's one of the most fundamental OO patterns after the Singleton.

[Weltchy]

Tell me about it. Reflection is one of those things that is really useful to know, but something you'll only use once or twice a year!!!

So I take it that you've got a static method in the concrete class that inherits from the base, and for some reason the stack trace isn't returning any frames?

Or have you overridden the base class's method?

[ASB]

I used this to return the calling assembly name for a bizTalk Orchestration. [n] = the number of levels up you want to go. The namespace your after is System.Diagnostics and System.Reflection. If you can't convert this to VB.NET, then you need a slap in the head!!!!

StackTrace stackTrace = new StackTrace();
StackFrame stackFrame = stackTrace.GetFrame([n]);
MethodBase methodBase = stackFrame.GetMethod();
return methodBase.DeclaringType.FullName;

Wading through whats where in reflection just gets so boring.

When invoked from a static declaringtype seems to be nothing when it's a derived class

But I'm probably just looking in the wrong place

Still, I have for the time being implemented a fairly grotesque hack in the calling code which lets me achieve what I want.

Cheers,

[Weltchy]

Don't mean to rain on your parade, but what screwed up design would need a base class to know anything about which derived class called it?

How can a base class ever be expected to know what future derived classes there might be and how should it know how to behave differently in each case?

Sounds like a bad case of arse about face design.

I've used it for application logging and management, so I know what calling method and assembly fell over, which then gets fed out to managed email groups, depending on the calling orchestration/application.

[Weltchy]

I used this to return the calling assembly name for a bizTalk Orchestration. [n] = the number of levels up you want to go. The namespace your after is System.Diagnostics and System.Reflection. If you can't convert this to VB.NET, then you need a slap in the head!!!!

StackTrace stackTrace = new StackTrace();
StackFrame stackFrame = stackTrace.GetFrame([n]);
MethodBase methodBase = stackFrame.GetMethod();
return methodBase.DeclaringType.FullName;

[Joe Black]

Not sure what it is in VB.Net.. but in C# you should be able to accomplish this by using Reflection

As Mr/Ms 3ill says, you can find just about everything you need via reflection. Sometimes perhaps in a round-about way. and there may be a performance penalty (but then that's what caching/pooling is for), but one way or another you can achieve what you want.

Certainly so far as 'private' is private goes it just doesn't exist in .NET...

[DimPrawn]

If you want to know if any given type implements an interface you can:

(C#)

if (typeof(IWhateverable).IsAssignableFrom(myType)) 

where myType is the type you want to check.

[ASB]

Thanks Guys.

I'll check out 3ill's reflection suggestion. That look promising.

As to "what screwed up design" I'll elaborate a little.

Firstly, the final design for where I am going to end up will include the right properties etc, but I have to migrat about 200,000 lines of procedural cobol as part of the process of evolving.

First step is getting this running in .NET and implementing a part of the new framework. The requirement for the lash up arises because the cobol programs get compiled into one object with one static method. I'm trying to avoid having to do too much in one hit just to get it running initially.

I'm also interested in DimParwns comment: "How can a base class ever be expected to know what future derived classes there might be and how should it know how to behave differently in each case?".

Well - would it be unreasonable to demand a derived class has implemented a specific interface?

[thunderlizard]

"I guess I'm just going to have to inherit the concrete implementation and modify it."

That is definitely the best option.

The Prawn is right. If your base class is supposed to know what the derived class is, then you're not doing inheritance. You'd be playing with fire. Inheritance is a one way street.

[VectraMan]

intA = asbContrete.SomeProperty

I haven't done basic since I had an Oric 1, but you're not trying to get the caller, you're trying to get the object the method (assuming it's equivalent to a method) is called on.

Assuming it works the same as C++, and "shared" is "static" then essentially the asbConcrete. part gets compiled out and is just used for compile time name resolution. So I don't see how you could possibly ever do a run time test as the information simply doesn't exist at runtime.

Can you not put a "SomeProperty" into asbConcrete as well, or does VB not allow that?

I think this falls firmly in the camp of: if you need to ask this your whole approach is wrong. But I understand you're trying to bodge something into an existing system rather than produce a new elegant solution.

[DimPrawn]

CowboyBob,

Yes. I realise I can do that. But that is not actually what I am trying to achieve.

Ideally I need to do it without changing the already existing code. :-(.

The existing code inherits a baseClass. A shared member is invoked. This goes into the new base class.

This in turn simply needs to know which class is calling it. Unfortunately there is nothing in the interface the currently exists which enables me to detemine this.

I guess I'm just going to have to inherit the concrete implementation and modify it.

Don't mean to rain on your parade, but what screwed up design would need a base class to know anything about which derived class called it?

How can a base class ever be expected to know what future derived classes there might be and how should it know how to behave differently in each case?

Sounds like a bad case of arse about face design.

[3ill]

CowboyBob,

Yes. I realise I can do that. But that is not actually what I am trying to achieve.

Ideally I need to do it without changing the already existing code. :-(.

The existing code inherits a baseClass. A shared member is invoked. This goes into the new base class.

This in turn simply needs to know which class is calling it. Unfortunately there is nothing in the interface the currently exists which enables me to detemine this.

I guess I'm just going to have to inherit the concrete implementation and modify it.

Not sure what it is in VB.Net.. but in C# you should be able to accomplish this by using Reflection

e.g.

MethodBase.GetCurrentMethod().ReflectedType should return you the type of the class that called that property.