DLL with callback problem RRS feed

  • Question

  • I have made a simple dll with C for use in an Ms Access vba project. The dll makes a new thread and  makes use of a vba callback function inside the thread's code. According to MS documentation the  vba callback function has to be in a vba module and not in a form's code.  Inside the callback function I set a form's filter property. But because  of this the Access crashes when the execution it arrives there!!! Why?  Other references to form's components have no problem (for example when I  set the value of the form's textbox)
    The mysterious is that I found the problem exists only when the vba Callback Sub is called  from the Thread function (ThreadFunc). If it is called from within dll main thread then form's filter is set ok without crash (!!!)

    Is this an MS Access bug?


    The C dll code compiled with VS 2017:

    #include <windows.h>
    #include <stdlib.h>
    #include <tchar.h>
    typedef void(__stdcall * CallbackFunction)();
    DWORD __stdcall ThreadFunc(CallbackFunction Callback) {
        return 0;
    __declspec(dllexport) void __stdcall message(CallbackFunction Callback) {
         // Array to store thread handles
        HANDLE Array_Of_Thread_Handles[1];
        Array_Of_Thread_Handles[0] = CreateThread(NULL, 0, ThreadFunc, Callback, 0, NULL);
    And here is the code that call the dll function "message" from within vba
    Private Sub Form_Load()
        Call message(AddressOf Callback)
    End Sub
    The vba Declaration of dll
    Public Declare Sub message Lib "test.dll" Alias "_message@4" (ByVal Callback As Long)
    The vba callback subroutine (resides on a Module according to MS documentation)
    Public Sub Callback()
        On Error Resume Next
        Forms("MyForm").txtTest="test" 'this line executed well and the string "test" appears ok in the form.
        Forms("MyForm").Filter="" 'in this line Access crashes out
    End Sub


    Tuesday, May 28, 2019 8:32 AM

All replies

  • This gets into the big topic of Thread Safety. I would not go there if I were you.


    -Tom. Microsoft Access MVP

    Tuesday, May 28, 2019 1:20 PM
  • Hi thank you for your response.

    It does not depend on me unfortunately. We have a large enough application that works for years and we want to add the ability to watch a text file if it changes. This means that a thread should be created to monitor the folder that the text file belongs to and when this happens a vba callback function must be called and filters the records.

    it seems that Access is too little to deal with, but it is not a solution to make the whole application from scratch in another platform only to deal with this.


    • Edited by nonlinearly Wednesday, May 29, 2019 1:22 PM
    Wednesday, May 29, 2019 1:15 PM
  • The threading issues I am hinting at do not care who it depends on. You already know of a solution: the main thread has to issue the callback. I would encourage you to go with that flow.

    -Tom. Microsoft Access MVP

    Thursday, May 30, 2019 1:53 AM
  • One possibility to consider is to use COM.  For example your code might do something like this -

    VBA instantiates an STA COM object and passes it the address of the callback function. 

    The COM object saves the address of the callback function.  The COM object exposes a method that will invoke the callback function.

    The COM object starts a worker thread and marshals its interface to the new thread.

    The worker thread initializes COM and unmarshals the interface. It will receive a proxy.

    The worker thread does its thing and at some point the worker thread calls the COM method on the proxy to invoke the VBA callback function.

    The COM run-time marshals the call from the proxy in the worker thread to the COM object instantiated in the VBA thread.

    The COM object in the VBA thread invokes the callback on the VBA thread.

    Sunday, June 2, 2019 10:09 PM
  • I don't know how to make a COM component. I will try because I thing that COM is more robust than a simple unmanaged dll to make collaboration between two applications written in different languages
    Monday, June 3, 2019 9:19 AM