[2008] Call parent function from DLL

[JacquesLebrun]

I have a bunch of VB.NET programs that have a general purpose logging function to log events, errors, exceptions, etc. It looks like this:

Sub LogMe(Msg as string)
   LstLog.items.add(now.tostring & " " & Msg)
End Sub

I wrote a few VB.NET DLLs that contain classes used my my VB.NET programs. In thoses DLL classes, I would like to also trap some events, errors, exceptions, etc. But I want them to be logged using my main LogMe function. Here is some pseudo-code of what I was looking for:

' Main program code

imports MyLib

' Initialize program
Private Sub FrmMain()
   FrmMain.Show
   FrmMain.LstLog.Clear
   MyLib.InitCallBack(Address_of_LogMe)
End Sub

' Log message to ListBox
Sub LogMe(Msg as string)
   LstLog.items.add(now.tostring & " " & Msg)
End Sub

' DLL library code

Public Module Globals

Private PointerLogMe as ??? = nothing

' Initialize Call Back function by main program
Public Sub InitCallBack(AddressLogMe as ???)
   PointerLogMe = AddressLogMe
End Sub

' Local logging function that actually does the CallBack to the main program
Private Sub LocalLogMe(Msg as string)
   If not PointerLogMe is nothing Then
      Call_function_stored_inPointerLogMe_with_Msg_as_a_parameter
   End if
End Sub

...
LocalLogMe("An exception was detected in function XXX")
...

End Module

I assume I will need to define Delegates to save my LogMe fonction pointer, but after a lot of Googling, I was not able to figure out how to code this.

Thanks

[Shaggy Hiker]

It seems to me that you will have a problem with this because there is no place to define the delegate. If you put it in the main project, then the dlls wouldn't recognize the type. If you put it in any dll, then the other dlls wouldn't recognize it.

I solved a similar problem in a project I am currently working on, but in my case, there was LOTS more that was going to be shared, so it may not map perfectly to your situation. In my case, I wanted either the dlls or the main form to be able to raise events and handle events from other places. What I ended up doing was creating a common dll that all the others included. The main program then created an instance of a single object that was defined in this common dll, and passed this object to the classes in each dll (at least the ones that needed to handle the events). That way they all shared a single object, and could all handle events raised by that single object.

That may be excessive for you, as all you really need to have in the common dll would be that delegate definition, but one of the other items I had in the common dll was an error log object. Any other class could have one of those error log objects as a member, and the error log object raised an event whenever anything was added to the log (the log was really just a List (of String)). Therefore, any object that had an error log object as a member could trap the error added event raised by the error log. Eventually, I decided that the thing to do was to then re-emit the event from each class in that global event object. Since events from the global event object were being handled by the main project, this meant that every class could just write to their error log and the main project would get a notification of that addition. Of course, every class that did that also had to handle the event from the error log and re-raise it on the global event object, but that just meant copying and pasting a one line method.