Kbase 17448: ACTIVEX - When is a DLL not a DLL? (Errors 3258, 3260, 5890)
Autor |
  Progress Software Corporation - Progress |
Acesso |
  Público |
Publicação |
  11/4/2008 |
|
Status: Verified
FACT(s) (Environment):
Windows
SYMPTOM(s):
Could not load DLL procedure <procedure>. (3258)
Could not find the entrypoint <function>. (3260)
Error occurred while accessing component property/method: <property or method name>.
<COM message>
Error code: <Program name> (5890)
CAUSE:
There are two different types of DLL's in the Windows environment: Com Objects DLL and "standard" DLL
A file ending with a DLL extension can now refer to one of two
completely different types of executable code.
The original definition of a DLL is a file containing executable
object code which is loaded into memory by another program and then
is available to have it's functions (one or more) called by the
program which loaded it into memory. This functionality came about
as a way to reduce the amount of memory needed by a program by
allowing a program to dynamically load object code into memory, call
functions within that code and then release the code from memory.
This also allowed the operating system to load only one copy of the
DLL into memory when multiple separate programs referred to the DLL.
Within Progress this type of DLL is called by using a combination of
the external procedure definition and the RUN statement. For more
information on this please refer to Chapter 5 of the Progress External
Program Interfaces manual.
With the advent of the Component Object Model (COM) technology from
Microsoft a DLL is now also used for a COM Object (ActiveX object).
To call these new COM/ActiveX DLL's you must use the ActiveX
Automation support within Progress. Please refer to chapters
7 and 8 of the External Program Interfaces manual for more information
on calling this new type of DLL.
FIX:
Please follow these steps to determine if a DLL is an ActiveX DLL.
1) Was the DLL created using either Microsofts Visual Basic 4.0,
Visual Basic 5.0 or Visual FoxPro products?
If so, then the DLL is an ActiveX DLL.
2) Did you have to register the DLL on your system (using REGSVR32)
before you could use it?
If so, then the DLL is an ActiveX DLL.
3) Did you get either error 3258 or 3260 when trying to access the
DLL via the RUN statement?
If so, did you verify that the DLL is a 32-bit DLL and all of the
correct supporting files (i.e. runtime libraries) which the DLL
needs are installed in the proper locations (according to the
documentation for the DLL)?
If so, then the DLL is an ActiveX DLL.
4) Did you have to install a type library (.TLB or .OLB) file along
with the DLL?
If so, then the DLL is an ActiveX DLL.
PLEASE NOTE:
Error 3260 error may also be generated due to the case sensitivity of the name of the External Procedure Function being called. Thus, while the following statement:
PROCEDURE WinExec EXTERNAL "kernel32.dll"...
Will work properly, either one of its following two variations:
PROCEDURE winExec EXTERNAL "kernel32.dll"...
PROCEDURE WINEXEC EXTERNAL "kernel32.dll"...
Will fail and produce error 3260 due to the case sensitive nature of these External Procedure Function " WinExec " being called.