non-COM DLL callback

[David]

Hi all,

I am new to .Net environment.
I have created a flat non-COM DLL from Visual C++ 6.0.
It stores up a function pointer from caller,
create a worker thread via WIN32 API,
and then call back the application within the worker thread.
Now, I created an application in VB.NET to use the DLL, and
it seems works fine.

I am not quite understand what is mananged and unmanaged code.
but seems that my DLL is called unmanaged code and
the code in VB is called managed code.
Is there any potential hazard in directly calling unmanaged DLL?
and also is it safe to call-back managed code from a thread in unmanaged
DLL?

What should I do in order to make it safe?

Here are some fragments of my code

In Application:

Module Module1

Public Declare Function RegisterEventHandler Lib "my.dll" _
Alias "_RegisterEventHandler@4" (ByVal lProcAddress As TEventHandler) _
As Integer

Delegate Sub TEventHandler(ByVal param As Integer)

Public Sub EventHandler(ByVal param As Integer)
Alter UI in Form1
.....
End Sub

End Module

Friend Class Form1
Inherits System.Windows.Forms.Form
Sub mySub()
RegisterEventHandler(AddressOf EventHandler)
End Sub
End Class

************************************************** *******

In DLL:

typedef void (CALLBACK* TEventHandler)(DWORD param);

TEventHandler EventHandler=NULL;
BOOL __declspec(dllexport) __stdcall RegisterEventHandler(long lProcAddress)
{
EventHandler = lProcAddress
hThread = CreateThread(NULL, 0, (LPTHREAD_START_ROUTINE)&worker, NULL,
0, &pThreadId);

Return TRUE;
};

void worker(LPVOID lpParam)
{
....
loop{
EventHandler(param);
}
}

[Tom Shelton]

On Thu, 29 Jul 2004 11:45:02 +0800, David wrote:

Hi all,

I am new to .Net environment.
I have created a flat non-COM DLL from Visual C++ 6.0.
It stores up a function pointer from caller,
create a worker thread via WIN32 API,
and then call back the application within the worker thread.
Now, I created an application in VB.NET to use the DLL, and
it seems works fine.

I am not quite understand what is mananged and unmanaged code.
but seems that my DLL is called unmanaged code and
the code in VB is called managed code.
Is there any potential hazard in directly calling unmanaged DLL?
and also is it safe to call-back managed code from a thread in unmanaged
DLL?

What should I do in order to make it safe?

Here are some fragments of my code

In Application:

Module Module1

Public Declare Function RegisterEventHandler Lib "my.dll" _
Alias "_RegisterEventHandler@4" (ByVal lProcAddress As TEventHandler) _
As Integer

Delegate Sub TEventHandler(ByVal param As Integer)

Public Sub EventHandler(ByVal param As Integer)
Alter UI in Form1
.....
End Sub

End Module

Friend Class Form1
Inherits System.Windows.Forms.Form
Sub mySub()
RegisterEventHandler(AddressOf EventHandler)
End Sub
End Class

************************************************** *******

In DLL:

typedef void (CALLBACK* TEventHandler)(DWORD param);

TEventHandler EventHandler=NULL;
BOOL __declspec(dllexport) __stdcall RegisterEventHandler(long lProcAddress)
{
EventHandler = lProcAddress
hThread = CreateThread(NULL, 0, (LPTHREAD_START_ROUTINE)&worker, NULL,
0, &pThreadId);

Return TRUE;
};

void worker(LPVOID lpParam)
{
....
loop{
EventHandler(param);
}
}

A couple of things... It should be safe to call your callback from another
thread, but don't access the GUI from it. Windows forms are not thread
safe. If you need to update the UI, then look at the Control.Invoke (or
BeginInvoke) method. You can find out if a call to Invoke is necessary by
checking the InvokeRequired property:

' the method assumes your in a form and want to access gui elements
Private Sub CurrentMethod(sender As object, e as eventargs)
If Me.InvokeRequired Then
Dim d As EventHandler = AddressOf Me.CurrentMethod
Me.Invoke(d, new Object() {sender, e})
Else
' do stuff to alter the gui
end if
end sub

Obviously, the type of the delegate depends on your method :)

Another thing to keep in mind is make sure you keep a reference to your
callback that you sent to unmanged code around. If you don't and gc runs,
then it will clean up the delegate and the address will no longer be valid
and you will more then likely crash the runtime :)

Private d As mydelegatetype

private sub callthecallback()
me.d = addressof me.mycallbackfunction
theunmanagedfunction(d)
end sub

That's the only two things I can think of right now that might get you into
trouble if you're not careful...

--
Tom Shelton [MVP]

[David]

Tom Shelton wrote:

On Thu, 29 Jul 2004 11:45:02 +0800, David wrote:

Hi all,

I am new to .Net environment.
I have created a flat non-COM DLL from Visual C++ 6.0.
It stores up a function pointer from caller,
create a worker thread via WIN32 API,
and then call back the application within the worker thread.
Now, I created an application in VB.NET to use the DLL, and
it seems works fine.

I am not quite understand what is mananged and unmanaged code.
but seems that my DLL is called unmanaged code and
the code in VB is called managed code.
Is there any potential hazard in directly calling unmanaged DLL?
and also is it safe to call-back managed code from a thread in unmanaged
DLL?

What should I do in order to make it safe?

Here are some fragments of my code

In Application:

Module Module1

Public Declare Function RegisterEventHandler Lib "my.dll" _
Alias "_RegisterEventHandler@4" (ByVal lProcAddress As TEventHandler) _
As Integer

Delegate Sub TEventHandler(ByVal param As Integer)

Public Sub EventHandler(ByVal param As Integer)
Alter UI in Form1
.....
End Sub

End Module

Friend Class Form1
Inherits System.Windows.Forms.Form
Sub mySub()
RegisterEventHandler(AddressOf EventHandler)
End Sub
End Class

************************************************ *********

In DLL:

typedef void (CALLBACK* TEventHandler)(DWORD param);

TEventHandler EventHandler=NULL;
BOOL __declspec(dllexport) __stdcall RegisterEventHandler(long lProcAddress)
{
EventHandler = lProcAddress
hThread = CreateThread(NULL, 0, (LPTHREAD_START_ROUTINE)&worker, NULL,
0, &pThreadId);

Return TRUE;
};

void worker(LPVOID lpParam)
{
....
loop{
EventHandler(param);
}
}

A couple of things... It should be safe to call your callback from another
thread, but don't access the GUI from it. Windows forms are not thread
safe. If you need to update the UI, then look at the Control.Invoke (or
BeginInvoke) method. You can find out if a call to Invoke is necessary by
checking the InvokeRequired property:

' the method assumes your in a form and want to access gui elements
Private Sub CurrentMethod(sender As object, e as eventargs)
If Me.InvokeRequired Then
Dim d As EventHandler = AddressOf Me.CurrentMethod
Me.Invoke(d, new Object() {sender, e})
Else
' do stuff to alter the gui
end if
end sub

Obviously, the type of the delegate depends on your method :)

Another thing to keep in mind is make sure you keep a reference to your
callback that you sent to unmanged code around. If you don't and gc runs,
then it will clean up the delegate and the address will no longer be valid
and you will more then likely crash the runtime :)

Private d As mydelegatetype

private sub callthecallback()
me.d = addressof me.mycallbackfunction
theunmanagedfunction(d)
end sub

That's the only two things I can think of right now that might get you into
trouble if you're not careful...

Thanks for your advice.

However, one of the UI in my form is a ListView
control(AxMSComctlLib.AxListView rather than
System.Windows.Forms.ListView. It was a upgraded project from VB6. I
don't know why the upgrade tool did such choice). Seems AxListView does
not provide InvokeRequired, What should I do?
I am sorry that I am not very good in VB6 too and don't know the
arhitecture of VB UI and multithreading.

Thanks.