Here's a quick sample of creating a Kernel event:
EventWaitHandle theEvent = null;
try // Try and open the Event
{
theEvent = EventWaitHandle.OpenExisting("THEEVENT");
}
catch (WaitHandleCannotBeOpenedException)
{
// Cannot open the AutoResetEvent because it doesn't exist
}
// Create it if it doesn't exist
if (theEvent == null)
{
theEvent = new EventWaitHandle(false,
EventResetMode.AutoReset, "THEEVENT");
}
You could make one process wait with "theEvent.WaitOne()" and then other
AppDomain or Process can call "theEvent.Reset()" to fire the signal everyone
that is waiting. I don't know exactly how you want to use it, but one of
the kernel objects (Event, Semaphore and Mutex) all work really well across
process.
Thanks,
Shawn Wildermuth
http://adoguy.com
C# MVP, MCSD.NET, Author and Speaker
-----Original Message-----
From: Discussion of advanced .NET topics.
[mailto:[EMAIL PROTECTED] On Behalf Of Dean Cleaver
Sent: Tuesday, April 11, 2006 1:28 AM
To: [email protected]
Subject: Re: [ADVANCED-DOTNET] Interprocess notifications
Thanx - when I looked at the help files, it showed it in a multi-threaded
environment, which isn't much use. I will check out these samples and see
what I can figure out.
Cheers!
Dino
-----Original Message-----
From: Discussion of advanced .NET topics.
[mailto:[EMAIL PROTECTED] On Behalf Of Shawn Wildermuth
Sent: Tuesday, 11 April 2006 17:24
To: [email protected]
Subject: Re: [ADVANCED-DOTNET] Interprocess notifications
It's not a traditional delegate based event, but a named event created in
the kernel. Look at System.Threading.ManualResetEvent class. They have a
good example (you typically use a shared name to share it across multiple
appdomains or processes). Here are a coupel of articles that walk you
through it:
http://msdn2.microsoft.com/en-US/library/ksb7zs2x(VS.80).aspx
http://www.codeproject.com/csharp/eventsthreadsync.asp
Thanks,
Shawn Wildermuth
http://adoguy.com
C# MVP, MCSD.NET, Author and Speaker
-----Original Message-----
From: Discussion of advanced .NET topics.
[mailto:[EMAIL PROTECTED] On Behalf Of Dean Cleaver
Sent: Tuesday, April 11, 2006 1:15 AM
To: [email protected]
Subject: Re: [ADVANCED-DOTNET] Interprocess notifications
How do I wire an event across 2 AppDomains that I have no control over
creating?
Dino
-----Original Message-----
From: Discussion of advanced .NET topics.
[mailto:[EMAIL PROTECTED] On Behalf Of Shawn Wildermuth
Sent: Tuesday, 11 April 2006 17:08
To: [email protected]
Subject: Re: [ADVANCED-DOTNET] Interprocess notifications
Why not an Event? Kernel objects are typically used for Cross Process
communication. For what you need, you probably need a ManualResetEvent
(look in System.Threading).
Thanks,
Shawn Wildermuth
http://adoguy.com
C# MVP, MCSD.NET, Author and Speaker
-----Original Message-----
From: Discussion of advanced .NET topics.
[mailto:[EMAIL PROTECTED] On Behalf Of Dean Cleaver
Sent: Tuesday, April 11, 2006 12:53 AM
To: [email protected]
Subject: [ADVANCED-DOTNET] Interprocess notifications
Hi,
I've got a situation where I need to communicate a change of state between 2
processes (or rather between what I presume are 2 AppDomains in one process)
where I have no real control.
Basically, I have an Outlook addin that adds a button to Outlook, and from
there they can switch the addin from server to local mode. The exact same
assemblies are also called via COM to create the usercontrols that are
inserted into HTML in the Outlook folders, but experience has shown that
they are in different AppDomains, or at least have different copies of my
assemblies as evidenced by the start-up code executing twice - once on start
of the Addin, and once when the first COM control is loaded, so I can't just
set a flag in the application. But I have no control over the AppDomains
that either are loaded into - that's all controlled by Outlook and the
Visual Studio Tools for Office.
Something I have tried but it failed is remoting - it seems that I can't
remote to the same target from within the same process twice, even if from
different AppDomains. Did not investigate greatly, however the exact same
piece of code would work for the Addin, but then fail for the COM controls.
Tried some different options of TcpListeners etc, to no avail. The remoting
would work for the COM controls from within a Windows Application however
where the Addin was not present.
Only thing I can think of is possibly windows messaging, but unless one of
my COM controls is displayed, I might not have a window in the COM controls
AppDomain to receive a message - in fact it might not yet be loaded by
Outlook at all. Ideally it needs to be an instant message, so adding a flag
to registry is not really appropriate because I'd rather not poll something
like that if avoidable.
Any other suggestions on how I might deal with this?
TIA
Dino
===================================
This list is hosted by DevelopMentor. http://www.develop.com
View archives and manage your subscription(s) at http://discuss.develop.com
===================================
This list is hosted by DevelopMentor(r) http://www.develop.com
View archives and manage your subscription(s) at http://discuss.develop.com
===================================
This list is hosted by DevelopMentor. http://www.develop.com
View archives and manage your subscription(s) at http://discuss.develop.com
===================================
This list is hosted by DevelopMentor(r) http://www.develop.com
View archives and manage your subscription(s) at http://discuss.develop.com
===================================
This list is hosted by DevelopMentor. http://www.develop.com
View archives and manage your subscription(s) at http://discuss.develop.com
===================================
This list is hosted by DevelopMentor® http://www.develop.com
View archives and manage your subscription(s) at http://discuss.develop.com
