Member Avatar for drew010

ive made a dll in c, and it gets called with visual basic.
in vb one of the parameters i pass is the address of a vb function.
i can get the dll to run the function fine, but i need to put that address into a struct to pass into a thread, which is where my problem is.

i have typedef'd the function pointer as

typedef void (*vbFuncEntry)(int);

a simplified version of the dll function header is

__declspec(dllexport) int __stdcall Function(LPTSTR msg, vbFuncEntry vbFE);

inside that function if i do something like

(vbFE)(500);

it calls the vb function no problem.

but when i try to assign that address into a struct, and call it later it doesnt work. im sure it just has to do with the fact that im assigning it wrong.

i have

typedef struct {
  char *msgPtr;
  vbFuncEntry funcEntry;
} info, *pinfo;

//and later on in the exported dll function

pinfo p2info = HeapAlloc(hHeap, HEAP_ZERO_MEMORY, sizeof(info));
p2info->funcEntry = vbFE;

//in the thread when i call
(p2info->funcEntry)(500);  //the program crashes

again i just think im doing that pointer assignment wrong, or it needs to be a pointer to a function pointer and i dont know how to do the assignment for it.

thanks for any help :)

Edited by Dani because: Fixed formatting
  • 2 Contributors
  • 3 Replies
  • 121 Views
  • 1 Week Discussion Span
  • Latest Post Latest Post by perniciosus

Dani AI

Generated

Brief summary and where to look next: demonstrated the callback address is identical when printed, so the struct assignment itself is almost certainly fine. The crash only happens when the stored pointer is invoked from a thread, so the two likely causes are (a) a calling-convention mismatch and (b) invoking VB runtime code from a worker thread. was on the right track about calling convention — but even with the right prototype, VB (especially VB6) generally expects calls on its main/UI thread.

Make the function-pointer type and thread creation explicit. If the VB callback uses stdcall (typical), declare the pointer with that convention (or use CALLBACK). Also avoid CreateThread if the thread will use CRT functions — prefer _beginthreadex. Example prototypes that illustrate the ideas (not duplicating your earlier lines):

typedef void (__stdcall *VBCallback)(int);

unsigned __stdcall WorkerThread(void *arg) {
  // worker work...
  // signal main thread instead of directly calling VBCallback from here
  return 0;
}

HANDLE h = (HANDLE)_beginthreadex(NULL, 0, WorkerThread, p2info, 0, &tid);

Do not call VB code from a worker thread. Instead marshal the result back to the main thread by one of these common patterns: post a custom Windows message (PostMessage) with the result pointer to a VB window, queue the result in the DLL and let VB poll an exported getter, or expose a COM object and let COM marshal calls to the STA. If using COM/ActiveX, initialize the thread with CoInitializeEx and follow apartment rules. When using PostMessage, be mindful of pointer sizes on different platforms and cast safely to WPARAM/LPARAM.

Practical debugging steps: step into the call from a native debugger to see the stack imbalance; try invoking the callback from the main thread only (to confirm thread affinity is the issue); and switch the typedef to include __stdcall to rule out convention mismatch. The prints you made already show the pointer is correct — focus on calling convention and VB thread rules rather than the HeapAlloc/assignment.

Recommended Answers

All 3 Replies

Member Avatar for perniciosus

Hmm, nwm (tried that with regular code and it worked fine)...

Member Avatar for drew010

hey, thanks for the reply. i t turns out i dont think the assignment was my problem after all. just to make sure i ended up printing the memory address of the function pointer in different places in the code, and they all yielded the same address. i have a feeling the problem is that im trying to call it from inside a thread i crated. i didnt find anything on msdn createthread that would indicate that you cant call a function pointer in a thread, so i have a feeling it has to do more with vb than the c code. vb probably doesnt like creating a thread and then having it try to call another procedure inside the program. i have just decided to live with the application hanging for a second while it does its thing, instead of trying to thread it off in the dll and call vb when it finishes.
thanks for your help. if anyone has any explanations as to why it crashes in the thread calling a func pointer, thatd be cool too.

Member Avatar for perniciosus

hey, thanks for the reply. i t turns out i dont think the assignment was my problem after all. just to make sure i ended up printing the memory address of the function pointer in different places in the code, and they all yielded the same address. i have a feeling the problem is that im trying to call it from inside a thread i crated. i didnt find anything on msdn createthread that would indicate that you cant call a function pointer in a thread, so i have a feeling it has to do more with vb than the c code. vb probably doesnt like creating a thread and then having it try to call another procedure inside the program. i have just decided to live with the application hanging for a second while it does its thing, instead of trying to thread it off in the dll and call vb when it finishes.
thanks for your help. if anyone has any explanations as to why it crashes in the thread calling a func pointer, thatd be cool too.

Hmm, I just thought of something...
My first thought was that vb and c may use different calling conventions, but since the regular code worked that seemed boggered...
But if the included header file defined the calling convention that could explain why it worked to to call it directly but not indirectly, however it should emit some warning on bad assignment though... But c beeing as it are usually be that you dont have warnings fully turned on or something.

And again that idea would also be buggered if you manage to do the indirect call without running it in a different thread (so you know you have isolated the exact cause of the problem, the next step would be to try to step though it in a debugger I guess)...

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.