MichaelTheRobot
Newcomer
- Joined
- Nov 13, 2003
- Messages
- 1
Hi everyone,
I'm working on a client-side remoting sink that attempts to determine which screen in my application is making the remoting request. "Screens" are different UserControl subclasses that are marked with a ScreenIdentificationAttribute. There is one Screen displayed at a time in the application, based on menu selections.
At first I tried looking back through the StackTrace at each frame, and checking to see whether the DeclaringType had my attribute. When I found the attribute, I'd know which Screen was making the call.
However, this scheme breaks down when a control on a Screen has event handling code that isn't defined in the Screen class. Normally all event handling code would be in the Screen class, so the Stack Trace would eventually find the event handling method, and find the DeclaringType of that method to be a Screen. However, when the event handler is in some other class, The StackTrace path goes straight from the Main() application method, through non-user code, to the event handler, through more nonuser code, to the client sink. The Screen class that owns the control does not appear in the StackTrace.
I'd like to always determine the calling Screen, but I don't know how to overcome this problem (short of moving all event handling code into the Screens, which isn't an option.) I thought that perhaps if I could determine the instance of classes making method calls in the StackTrace, I could search for a Control, then check the control's Parent property to find my Screen class. Does .NET provide this functionality?
Any other ideas would be greatly appreciated.
Thanks in advance,
Michael
I'm working on a client-side remoting sink that attempts to determine which screen in my application is making the remoting request. "Screens" are different UserControl subclasses that are marked with a ScreenIdentificationAttribute. There is one Screen displayed at a time in the application, based on menu selections.
At first I tried looking back through the StackTrace at each frame, and checking to see whether the DeclaringType had my attribute. When I found the attribute, I'd know which Screen was making the call.
However, this scheme breaks down when a control on a Screen has event handling code that isn't defined in the Screen class. Normally all event handling code would be in the Screen class, so the Stack Trace would eventually find the event handling method, and find the DeclaringType of that method to be a Screen. However, when the event handler is in some other class, The StackTrace path goes straight from the Main() application method, through non-user code, to the event handler, through more nonuser code, to the client sink. The Screen class that owns the control does not appear in the StackTrace.
I'd like to always determine the calling Screen, but I don't know how to overcome this problem (short of moving all event handling code into the Screens, which isn't an option.) I thought that perhaps if I could determine the instance of classes making method calls in the StackTrace, I could search for a Control, then check the control's Parent property to find my Screen class. Does .NET provide this functionality?
Any other ideas would be greatly appreciated.
Thanks in advance,
Michael