I still don't understand why abusing the remoting infrastructure helps you at all. Just use a static event, or a static naked delegate instance. Or, store a reference to your "main" form in a global field or property. The type system is your friend, not your enemy.
Your code should only interact with the remoting infrastructure if it involves remoting somehow. Abusing environment features will only get you in trouble later. -- arlie -----Original Message----- From: Unmoderated discussion of advanced .NET topics. [mailto:[EMAIL PROTECTED] On Behalf Of Ross Diesel Sent: Tuesday, April 20, 2004 12:16 PM To: [EMAIL PROTECTED] Subject: Re: [ADVANCED-DOTNET] Smuggling delegates via the context I recognise that I'm abusing the call context in this specific situation. The motivation was primarily an R&D one as it appeared to be the quickest mechanism (without reworking interfaces) to get a notification from any one of a number of modeless dialogs back to my main test harness dialog. The modeless dialogs essentially represent worker threads. Please note that the issue crops up even under a non-remoting context i.e. I knocked up a helper class which was instantiated after the delegate was stored in the context and a method invoked on the helper which tried to retrieve the delegate but I experienced the same result. Also, the following cast works in both the modeless dialog and the helper class... MulticastDelegate eh = (MulticastDelegate)Context.GetData(dss); another curious fact was that I could see the delegate (target method and instance) correctly in the debugger. regards =================================== This list is hosted by DevelopMentor� http://www.develop.com Some .NET courses you may be interested in: NEW! Guerrilla ASP.NET, 17 May 2004, in Los Angeles http://www.develop.com/courses/gaspdotnetls View archives and manage your subscription(s) at http://discuss.develop.com
