English Deutsch Français Italiano Español Português 繁體中文 Bahasa Indonesia Tiếng Việt ภาษาไทย
All categories

My employer will not spend the money to get me Visual Basic.Net. I am stuck using Visual Basic 6. I am pretty good with programming embedded C, but have no time to learn to program in Visual C++.


So I am doing some advanced programming, in VB6, using several DLL’s. I have 4 DLL’s, and two of them use callbacks. The problem is the GUI will appear to freeze during a DLL call. When the DLL returns, everything returns to normal. I have partly cured the problem by refreshing the forms, and calling DoEvents during callbacks. This works fine, unless the user clicks on a control button. The button event will not fire until the DLL returns, or during the callback. This makes the app very sluggish.

I have tried various methods of multi-tasking. Several of them work, in the IDE, but crash at runtime. The app will crash with an exception when one of the DLL’s executes a callback.

2007-03-21 12:37:46 · 1 answers · asked by Marvin 7 in Computers & Internet Software

The situation gets worse if I call a DLL from within a callback from another DLL. In other words multi –tasking will work on simple programs at runtime, but when you start using callbacks, that must have access to global variables, all bets are off.



We tried starting another thread in the DLL’s. The callback was called from a module. It was given the callback address within the module. The DLL, would then spawn a new thread, and then the main thread would return. The spawned thread would execute a callback when the GUI needed to prompt the operator to take some action. Communications between the main form and the callback took place using global semaphores. This worked great, in the IDE. I ran the app though all kinds of testing. I had the whole thing perfectly debugged. Then I discovered that it would crash at runtime!

2007-03-21 12:38:39 · update #1

1 answers

Not easy to follow everything you did, but I'd try something like this:
Make a worker thread that does the DLL calls. Keep or drop the callbacks. I guess you are using callbacks to signalize progress, if so you will have trouble - VB6 is too slow for that. If you're using callbacks for other things, it may be worth reconsidering them, I don't have good experience with callbacks in VB6.
The worker thread should send simple Windows Messages to signalize progress. Even in VB6 you can post/send Windows Messages.

The User Interface thread is the main VB thread, no modifications needed. To Windows Messages are trapped by subclassing some (main) window - good source code can be found for that on Internet. This read will be responsive all the time, and no risk of crashing.

2007-03-23 00:35:08 · answer #1 · answered by BataV 3 · 0 0

fedest.com, questions and answers