Question

I have a C dll that I'm wrapping so that I can call it from C#. One function uses events to notify you when a state has changed, and figuring out to deal with it took some digging. It seems to be working ok, but I'm curious if anyone has more experience with this than I do and can offer any advice.

The function is defined in the dll's .h file as:

int NotifyStateChange(OVERLAPPED *overlapped);  
typedef int (*NOTIFY_STATE_CHANGE_PROC)(OVERLAPPED *);  

Sample C code calling it:

OVERLAPPED overlapped;  
overlapped.hEvent = CreateEvent(NULL, FALSE, FALSE, NULL);  
fns.NotifyStateChange(&overlapped);  
WaitForSingleObject(overlapped.hEvent, INFINITE);  
// ...query for the new state or whatever...

This is how I approached it in C#:

[DllImport("myfuncs.dll")]
unsafe public static extern int NotifyStateChange(NativeOverlapped* lpOverlapped);

static private ManualResetEvent m_stateChangeEvent = new ManualResetEvent(false);

public static DeviceState WaitForStateChange()
{
    unsafe
    {
        Overlapped overlapped = new Overlapped(0, 0, 
            m_stateChangeEvent.SafeWaitHandle.DangerousGetHandle(), null);
        IOCompletionCallback callback = StateChangeCallback;
        byte[] userData = new byte[100];
        NativeOverlapped* nativeOverlapped = overlapped.Pack(callback, userData);
        NotifyStateChange(nativeOverlapped);
        m_stateChangeEvent.WaitOne();
        Overlapped.Unpack(nativeOverlapped);
        Overlapped.Free(nativeOverlapped);
    }
    return GetCurrentState();
}

[ComVisibleAttribute(true)]
unsafe static public void StateChangeCallback (
    uint errorCode, 
    uint bytesTransferred, 
    NativeOverlapped* overlapped)
{
    m_stateChangeEvent.Set();
}

One thing I'm unclear on is the need for userData. NotifyStateChange just fires an event, it doesn't return any data. Passing a null userData to Pack() seemed to work fine, but I'm concerned something may be going on with userData under the covers that I'm not aware of.

I appreciate any advice on if there's a more proper way to do this.

Eric

Was it helpful?

Solution

You are already blocking on the event handle, there is no need to use the Overlapped class and the callback. All you have to do is to set the NativeOverlapped.EventHandle member to the DangerousGetHandle() return value. The DLL will set the event.

Also, declare the argument for NotifyStateChange as ref instead of a pointer, saves you from having to use the unsafe keyword.

OTHER TIPS

Ah yes - that's exactly why I ask stackoverflow the hard questions. Seems obvious now. Here's the much simplified code...

    [DllImport("myfuncs.dll")]
    public static extern int NotifyStateChange(ref NativeOverlapped lpOverlapped);

    public static DeviceState WaitForStateChange()
    {
        ManualResetEvent stateChangeEvent = new ManualResetEvent(false);
        NativeOverlapped nativeOverlapped = new NativeOverlapped();
        nativeOverlapped.EventHandle = 
            stateChangeEvent.SafeWaitHandle.DangerousGetHandle();
        NotifyStateChange(ref nativeOverlapped);
        stateChangeEvent.WaitOne();

        return GetCurrentState();
    }

thanks!

Eric

It seems that the DLL designers have decided to use, for whatever reason, the OVERLOAPPED structure when they could had simply use a simple HANDLE for an event to signal. Apparently they to not look at the other fields in the OVERLAPPED structure, as the DLL does not appear to use it to perform any sort of I/O operation using the overlapped data (the pointer and offsets). So, without knowing much about said DLL, it would appear that your use is correct, and you can pass nil for data and 0 for offsets.

But bear in mind tis is just a guess. If possible, contact the DLL author(s) and ask for clarification if the assumption that they ignore the pointer and offsets is correct.

As a side note, I would not block a thread waiting for state changes if you're going to get a callback anyway. Just use the callback to process the event (state change), the system will scale much better.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top