Named Win32 events

[Andrei]

Hi all!

I know how to use named Win32 events via Win32 API, but I
wanna use them via C# and .NET Framework - is there any
solution? AutoResetEvent and ManualResetEvent wrapper
classes don't provide this functionality, do they?

Thanks all!

[Neil McKechnie]

I presume by 'named Win32 events' you mean messages
registered by name with the RegisterWindowMessage api call?

The AutoResetEvent and ManualResetEvent are used for
thread synchronisation and don't directly correspond to
windows messages. If you want to receive a named message
I believe that you will need to do what you did with the
Win32 API - that is subclass the window procedure to
process the required event.

In .Net this is just a matter of overriding the WndProc
method of the System.Windows.Forms.Form class, and
processing the supplied message as required.

The code required would be similar to that below:

Private Declare Auto Function RegisterWindowMessage _
Lib "User32" (ByVal Name As String) As Integer
Private MyMessageNo As Integer = _
RegisterWindowMessage("MyMessage")

Protected Overrides Sub WndProc(ByRef m As Message)
If m.Msg = MyMessageNo Then
MessageBox.Show("Message 400 received")
End If
MyBase.WndProc(m)
End Sub

>.
>

[Jerry III]

Neil, named Win32 events are not messages, they're synchronization objects
much like AutoResetEvent and ManualResetEvent except they have a name (see
CreateEvent API function, it takes a name). That way you can open an
existing event by its name, even an event created by different process
without having to rig some sort of interprocess communication.

Unfortunately I don't know if .Net framework supports anything like this...

Jerry

"Neil McKechnie" <Ne...@MicrolinkAssociates.co.uk> wrote in message
news:02dd01c38901$28b94930$a301...@phx.gbl...

[Mark Hurd]

I was hoping your request would flush out a more definitive response, but this
thread:

http://groups.google.com.au/groups?threadm=e2vFuE%24KDHA.2300%40TK2MSFTNGP10.phx.gbl&rnum=1

has me asking for confirmation that named Managed Mutexes can be safely
accessed cross-process and thus by unmanaged code.

Note that Brian Grunkemeyer [MS] in that thread states fairly clearly that
Managed code should only access Managed (wrappers for) synchronisation
objects, but he doesn't expand upon the opposite situation.

--
Regards,
Mark Hurd, B.Sc.(Ma.) (Hons.)

[Dave]

I haven't tried it myself but you should be able to p/invoke to the
unmanaged API and use the named synchronization primitives. You could also
try using the C# Mutex class to create a named mutex - I would expect it to
be visible to unmanaged mutexes.

"Andrei" <tr...@nm.ru> wrote in message
news:1da3901c388f1$b6751c50$a601...@phx.gbl...

[Mark Hurd]

Dave wrote:
> I haven't tried it myself but you should be able to p/invoke to the
> unmanaged API and use the named synchronization primitives. You could also

No, this is what has been generally advised against.

> try using the C# Mutex class to create a named mutex - I would expect it to
> be visible to unmanaged mutexes.

Yes, this seems to be the case, but we'd like some confirmation long-term...

[Dave]

"Mark Hurd" <mark...@ozemail.com.au> wrote in message
news:uVf0ORMj...@TK2MSFTNGP12.phx.gbl...

> Dave wrote:
> > I haven't tried it myself but you should be able to p/invoke to the
> > unmanaged API and use the named synchronization primitives. You could
also
>
> No, this is what has been generally advised against.
>

It's been advised against primarily because of the CLR's inability to abort
unmanaged threads. If you absolutely, positively need interprocess
auto/manual reset events then currently there isn't much choice. I
personally would avoid it unless I absolutely needed it and no other
mechanism worked, especially if all the threads were managed threads.

> > try using the C# Mutex class to create a named mutex - I would expect it
to
> > be visible to unmanaged mutexes.
>
> Yes, this seems to be the case, but we'd like some confirmation
long-term...
>

If it's supported in the current rev then use it - I don't believe it's
going to change anytime soon (too many other problems need to be solved). If
one day in the distant future they break it then you can devise another
means.