DLL problem...

[Michael Meeks]

Re Peter: MatLab is using ActiveX. But i dont think that this is a VB DLL.
The dll is made for C and FORTRAN-users. In the C header-files the functions are declared the stanard way.

Peter, if this is an ActiveX DLL, regardless of language it was
written in, you won't be able to access with just PB/DLL alone.

There maybe something in the 3rd Party area concerning ActiveX dll's.

mwm



------------------
mwm

Thanks Florent and Scott.

Florens --

1.) the dll cannot be found

I'm sure that it can be found. LoadLibraryEx can find it.

2.) the LoadLibrary function cannot locate the DllEntryPoint...

Yes. But isnt that strange. there is no DllEntryPoint in it! That's the reason that i have to use LoadLibraryEx.

3.) maybe Matlab has not installed properly

MatLab works fine on its own terms

The fact that you get a GPF UNLESS you decrement the value returned
by -1 seems to indicate that you are not getting a valid pointer
from GetProcAddress.

I have actually implementet severel functions. I have to do the '-1'-trick with them all to avoid the gpf's.
One of the functions (engClose) actually returns 1, wich according to the manual means error.

- is the matlab dll a true 32 bit dll

Dont know. I think so. Could be the problem though. The version i'm testing is several years old.

- Try looking at the libeng.dll with the "depends.exe" utility

I have used that utility. The functions are actually in the dll.

Scott --

I have tried upper case. According to depends.exe my mixed-case-way is correct.

MatLab is using ActiveX. But i dont think that this is a VB DLL.
The dll is made for C and FORTRAN-users. In the C header-files the functions are declared the stanard way.

Regards
Peter

------------------


[This message has been edited by Peter Stephensen (edited July 05, 2000).]

[Scott Turchin]

Another thing to consider is the case sensitivity of the function name.

It may be all upper case unless an alias has been declared.


And, unless y ou wrote the DLL, consider that it may be such as a VB DLL (ActiveX) in which case you can't use it in this manner.

Here's my sample from one DLL (It was activeX and gives me GPF's too)

Declare Function FreeCCSDLL Alias "FreeCCSDLL"(key As Asciiz, param As Asciiz) As Long 

'

Global hLib     As Long
Global pAddr    As Dword

hLib = LoadLibrary("FREECCS.DLL")
If hLib Then
    pAddr = GetProcAddress(hLib, "FreeCCSDLL")
    If PAddr = %NULL Then
          MsgBox "Could not find function ""FREECCSDLL"" in ""FREECCS.DLL""",%MB_ICONSTOP, CCS
    Else  
         Key = "Reset":Param = ""
         Call Dword pAddr Using FreeCCSDLL(Key,Param) To lResult
    End If
Else
    Msgbox "Unable to Locate FREECCS.DLL",%MB_ICONSTOP, g_szMine
End If

------------------
Scott
mailto:[email protected][email protected]</A>
MCSE, MCP+Internet

[Florent Heyworth]

Hi Peter

DONT_RESOLVE_DLL_REFERENCES is valid on NT only - since it would
suprise me that MATLAB dlls can't called from Win9.x something else
must be the matter.

If the LoadLibrary(Ex) call returns %NULL then:
1.) the dll cannot be found
2.) the LoadLibrary function cannot locate the DllEntryPoint - which
would mean that it is not a valid dll as far as I know
3.) maybe Matlab has not installed properly and it needs to
load additional modules not found on your hard drive before
returning SUCCESS and hence returns FAILURE unless called with
DONT_RESOLVE_DLL_REFERENCES which does not call the Entry point
function - and therefore since the DLL is not correctly loaded
you get a GPF when using the pointer returned by GetProcAddress.
This seems to be the most likely reason.

The fact that you get a GPF UNLESS you decrement the value returned
by -1 seems to indicate that you are not getting a valid pointer
from GetProcAddress. Can you actually call the function "engOpen"
with that pointer and get valid result? Is it possible to call other
functions after that?

A few more ideas:
- is the matlab dll a true 32 bit dll (no thunking required)?
- Try looking at the libeng.dll with the "depends.exe" utility
which will show you the exported functions
- Do a search on your hard drive - perhaps a conflicting dll with
the name "libeng.dll" also exists on your hard drive and is already
mapped in memory or the "wrong" dll is getting loaded.

Cheers

Florent


[This message has been edited by Florent Heyworth (edited July 05, 2000).]

I am trying to get in contact with the MATLAB-engine-dll (libeng.dll).
It seemes to be a strange dll.

First i tried this (with the function engOpen):

declare function engOpen cdecl lib "libeng.dll" alias "engOpen"(s as asciiz) as dword

No luck.

Then i tried:

global hEngineModule as long	
 
declare function ProtoType_engOpen cdecl (s as asciiz) as dword
 
function engOpen(startcmd as string) as long
 
	static lpfnengOpen as dword
	local ret as long
	local zstartcmd as asciiz*128 :	zstartcmd = startcmd
 
	if hEngineModule = 0 then hEngineModule = LoadLibrary($MATLAB & "\libeng.dll")
	if hEngineModule = 0 then exit function
 
	if lpfnengOpen = 0 then lpfnengOpen = GetProcAddress(hEngineModule, "engOpen") 
	if lpfnengOpen = 0 then exit function
 
	call dword lpfnengOpen using ProtoType_engOpen(zstartcmd) to ret
 
	function = ret
 
end function

No luck. LoadLibrary returned 0.

Then i tried this:

%DONT_RESOLVE_DLL_REFERENCE = &H000001
 
global hEngineModule as long	
 
declare function ProtoType_engOpen cdecl (s as asciiz) as dword
 
function engOpen(startcmd as string) as long
 
	static lpfnengOpen as dword
	local ret as long
	local zstartcmd as asciiz*128 :	zstartcmd = startcmd
 
	if hEngineModule = 0 then hEngineModule = LoadLibraryEx($MATLAB & "\libeng.dll", 0, %DONT_RESOLVE_DLL_REFERENCE)
	if hEngineModule = 0 then exit function
 
	if lpfnengOpen = 0 then lpfnengOpen = GetProcAddress(hEngineModule, "engOpen") - 1 
	if lpfnengOpen = 0 then exit function
 
	call dword lpfnengOpen using ProtoType_engOpen(zstartcmd) to ret
 
	function = ret
 
end function

This is a litle better. hEngineModule and lpfnengOpen are positive and the function returns a positive value.
But the overall functioning of the functions are not correct.
Observe the - 1 in the GetProcAddress-line.
If i dont add this i get a gpf.

Anybody got a clue?

Regards
Peter


------------------


[This message has been edited by Peter Stephensen (edited July 05, 2000).]