VB Run-time errors when calling a PowerBASIC DLL

There is one common and avoidable error that may be encountered when first attempting to use a PowerBASIC DLL with a Visual Basic application: Error 48 "Error in loading DLL" or "DLL not found".

In almost all circumstances involving this VB error, the problem is not that VB cannot find the DLL, rather, that VB is not able to locate the specified Sub/ Function inside the DLL. When this occurs, the problem is very likely to be due to mismatching capitalization of the Sub/Function and the VB Declare statement, or the Sub/Function has not been EXPORTed from the DLL.

To remedy these situations, either add an explicit ALAIS clause to the Exported PowerBASIC Subs and Functions to ensure that the exported name matches the VB Declare, or capitalize the VB Declare Sub/Function name. The latter solution works because PowerBASIC capitalizes all exported procedure (Sub, Function, Method, and Property) names that do not have an explicit ALIAS clause. For more information, please refer to the FUNCTION, SUB, METHOD, and PROPERTY topics.

In addition, VB Errors 53 and 453 may sometimes be resolved by the addition of an ALIAS clause.

In the design environment, it is common practice to provide an explicit path to the DLL in the LIB clause of the VB Declare statement. In the final "distribution" version, such explicit paths should be removed from the VB Declare statements. When the paths are omitted, Visual Basic use the following strategy to try to locate the DLL:

1. | Directory containing the calling EXE

2. | Current directory

3. | Windows 32-bit system directory

4. | Windows 16-bit system directory

5. | Windows directory

6. | Folders specified in the PATH environmental variable

Therefore, it is also possible that certain VB run-time errors (especially in the design environment) may be attributed to VB failing to locate the DLL, or that VB may be loading the wrong version/copy of the DLL. When debugging such issues, place the DLL in the appropriate VB project directory, and all rename or delete any other copies.

Problems calling DLLs, or General Protection Faults (GPFs) when the application runs/closes can often be attributable to errors in the Visual Basic declarations. Visual basic declarations should generally be placed in the declarations section of a Visual Basic module, rather than elsewhere in the project to avoid scoping issues. Declarations in a module should not use the Private Declare syntax.

General Protection Faults (GPFs) may also occur when incorrect parameters or passing methods are used with the DLL. Another source of GPF problems can occur if passed arrays are referenced beyond their boundaries from within the DLL code.

See Also

Visual Basic Data Types