FAQ (Frequently Asked Questions)
for Visual Basic 1.x-6.x developers on using WSQ image library
In Visual Basic it is not possible to directly call a C function in a DLL if that function uses the _cdecl calling convention. This is because Visual Basic uses the _stdcall calling convention for calling functions. This is a problem because if _cdecl is used, the calling function is responsible for cleaning up the stack. However, if _stdcall is used, the called function is responsible for cleaning up the stack.
The solution is to use wrapper DLL which wraps __cdecl calls into __stdcall calls.
Such a wrapper interface is provided in DLL file "WSQ_library_stdcall.dll"
Visual Basic first looks for the DLL in the default folder - under the IDE which is not necessarily the same as the App.Path.
When compiled it does.
The standard trick is to do:
before the first call into your DLL. You don't need it before every call into it, only the first, since that is what loads the DLL.
Also you need to ChDrive to the current application drive.
When your application is compiled, the DLL is always found in the first step, since your application now has its own "directory it was loaded from". The current directory no longer matters for loading the DLL.
Reset the current drive and folder with
commands (using App.Path as arguments) or use
| |
CommonDialog1.Flags = cdlOFNNoChangeDir |
Loading and Unloading DLLs in the Design Environment
Microsoft Knowledge Base Article ID: 129514 Last Review: December 9, 2003 Revision: 2.0
SYMPTOMS
You may not be able to overwrite a dynamic-link library (DLL) after calling into it from Visual Basic in design time while the Visual Basic design environment is still running. This problem is generally encountered when users are developing DLLs for Visual Basic and are debugging their DLL code.
CAUSE
When a function within a DLL is called by a program in the design environment, the DLL is loaded into memory. When the program is stopped, the DLL is kept in memory and is only unloaded when the user exits the design environment or when a hard edit is performed on a Declare statement that references the DLL. This prevents Visual Basic from having to load and unload DLLs every time the user runs and stops the program at design time.
RESOLUTION
You can force Visual Basic to unload a DLL by performing a hard edit on the Declare statement of a function that is declared within the DLL. For example, you can do a hard edit on the Declare statement by just deleting the "r" in "Declare" and then typing it back in. This forces a recompile, which causes Visual Basic to unload the DLL.
While theoretically both VB Classic and VB.NET are from the same family, in practice VB.NET is not compatible with VB 6 - not really even close, so migration even of simple VB projects to .NET presents quite a challenge.
If you are writing new application you should consider using Visual Basic .NET from the beginning.
Microsoft's mainstream support for VB6 officially ended on March 31st, 2005. Now that this has occurred, it becomes increasingly more likely that future updates to Windows may break existing VB code. If you are concerned about this and/or are concerned about migration issues associated with bringing existing VB code to the .NET platform, please take a moment to read and sign the petition
http://classicvb.org/Petition
asking Microsoft to extend there COM based VB product line. The impetus behind the petition is the desire to give companies and individuals with substantial investments in existing VB code a path forward to the latest development platform without the current requirement for wholesale rewrites of existing code.
|