Announcement

Collapse
No announcement yet.

DLL problem...

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Michael Meeks
    replied

    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

    Leave a comment:


  • Guest's Avatar
    Guest replied
    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).]

    Leave a comment:


  • Scott Turchin
    replied
    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)

    Code:
    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

    Leave a comment:


  • Florent Heyworth
    replied
    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).]

    Leave a comment:


  • Guest's Avatar
    Guest started a topic DLL problem...

    DLL problem...

    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):
    Code:
    declare function engOpen cdecl lib "libeng.dll" alias "engOpen"(s as asciiz) as dword
    No luck.

    Then i tried:
    Code:
    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:
    Code:
    %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).]
Working...
X