use freebasic dll with msaccess

[jj2007]

No idea why it doesn't work for you. Here (Windows 7-64), I call the DLL from MS Access using the full path - it's even on a different drive. No registration needed. I can't see a reason why it shouldn't work, this is a very, very basic Windows setup and procedure.

[deltarho[1859]]

I doubt that this will solve your problem but getting a successful dll creation is the easy part, getting it to work is the hard part. A simple mistake is enough to break an execution and the error message may not be helpful either.

You write "Function SayHello(text As string ptr) As integer EXPORT". 'text' defaults to 'ByVal text' in FreeBASIC so that is OK but it is best practice to say so, even if that is what you intended. However, what I am interested in is 'string ptr'. You got a warning!

Later you write 'Declare Function SayHello Lib "C:\testdll\sayhello.dll" (ByVal pString As String) As Integer' using 'ByVal pString As String'. That should be 'ByVal pString As String Ptr'.

Windows is not very good at homing in on parameter mismatching. We could get an 'invalid parameter' in a API of ten parameters but we do not get told which is the offending parameter. <smile>

Added: Remove 'ptr' in 'Function SayHello() and leave the declaration as is.

[srvaldez]

tried:
Declare Function SayHello Lib "C:\testdll\sayhello.dll" Alias "SayHello" (ByVal pString As String) As Integer
still same error message

tried placing dll in c:\windows\system32
same error message
removed dll from c:\windows\system32

I don't know if you are aware of this or not, but on Windows, the 64-bit dll goes in c:\windows\system32 and the 32-bit dll goes in C:\Windows\SysWOW64

[michaelleewebb]

deltarho, you may be on to something, msaccess doesn't handle pointers very well. i'm reading this web page:
https://codekabinett.com/rdumps.php?Lan ... si-unicode

looks complicated. and still may not work.

i had no idea that 32 bit dll's go into the syswow64. seems weird that 64 bits go into system32 and 32 bit goes into syswow64, that seems backwards.

[MrSwiss]

Some observations about a useful testing sequence:

• 1) Test 1: function which only has numeric data-types, as simplest test.
  2) Test 2: [only if 1) is successful] try with String (a additional hurdle)

Since Windows is written in C/C++ it does NOT understand "String" (like FB's RTlib.),
therefore we've to use: ByVal As ZString Ptr (conversion from String is
"built-in" to FB) to pass a "String" to Windows (or other programs).

[michaelleewebb]

mrswiss, i agree. i'm going to go back to my "addnumbers" example and try to apply what ive learned.

[deltarho[1859]]

i had no idea that 32 bit dll's go into the syswow64. seems weird that 64 bits go into system32 and 32 bit goes into syswow64, that seems backwards.

32-bit versions of Windows cannot run 64-bit binaries. 64-bit versions of Windows cannot run 32-bit binaries without emulation. The emulator makes 32-bit binaries think that they are running on 32-bit Windows.

[dodicat]

Because I don't have microsoft office or visual basic, I have spent half an hour with the built in vbscript.
Only to find now out that vbscript is unable to load dll's.

"Because VBScript is a subset of Visual Basic, you would expect that it supports the calling of DLLs. Unfortunately, as of this writing VBScript does not support it. This might change in the future. VBScript is the new kid on the block and continues to evolve as it gains wider acceptance. Future releases of VBScript might support DLL integration."

Never mind!

The format for vb seems to be
Declare Function AddNumbers Lib "C:\Users\User\Desktop\testdll\add.dll" alias "AddNumbers"(byval a As Integer,byval b As Integer) As Integer
where the full path is used for the dll.
Also I see that case is important, the alias string is case sensitive.
You should mess around with the case, try all upper case first then an exact case replica of the actual function in the dll (as above).

[michaelleewebb]

i tried this:
created new bas program called newaddnumbers.bas
this is the code:
#include once "windows.bi" ' To access Windows data types
Extern "Windows-MS"

Function addnumbers(byval x as integer, byval y as integer) As integer Export
function = x + y
End Function

End Extern
compiled without any warnings.

added this into the vba module:
Declare Function addnumbers Lib "C:\testdll\newaddnumbers.dll" Alias "AddNumbers" (ByVal x As Integer, ByVal y As Integer) As Integer

added this to the on click event:
Declare Function addnumbers Lib "C:\testdll\newaddnumbers.dll" Alias "AddNumbers" (ByVal x As Integer, ByVal y As Integer) As Integer
everything is in the proper folders.
same error message.
maybe i'm missing something. if not i was hoping that the "Extern "windows-ms" was going to fix the problem. guess not. mr swiss, i don't see a way to simplify the problem further.

[MrSwiss]

mr swiss, i don't see a way to simplify the problem further.

There is: before trying with all the Access specifics, try it from a FB program stub.

• 1) load DLL (with #Inclib "name") without ".dll" (observe case!)
  2) Function declaration
  3) accessing the contained Function

Only if this is successful, carry on ... (dig into Access Manuals).

[srvaldez]

you need to be mindful to use proper case in your alias, in your basic source, you declare the function addnumbers but in the VBA declaration "AddNumbers"
try

Code: Select all

Declare Function addnumbers Lib "C:\testdll\newaddnumbers.dll" Alias "addnumbers" (ByVal x As Integer, ByVal y As Integer) As Integer

[dodicat]

Try LoadLibrary() and GetProcAddress() as a last resort.
This works in freebasic

Code: Select all

#include "windows.bi"

'fb needs any ptr
#define Intptr any ptr

'======================

'visual basic loader
Dim lLibraryHandle As IntPtr = LoadLibrary("C:\Users\User\Desktop\testdll\add.dll")
Dim lFunctionHandle As IntPtr = GetProcAddress(lLibraryHandle, "AddNumbers")
'======================


'fb check
print lLibraryHandle
print lFunctionHandle

var addup=cast(function(as integer,as integer) as integer,lFunctionHandle)

print addup(7,8)

 sleep
   

[michaelleewebb]

srvaldez,
in msaccess if the function name and the alisa is the same msaccess automagicly removes the alisa statement

[deltarho[1859]]

you need to be mindful to use proper case in your alias

as dodicat mentioned

Also I see that case is important, the alias string is case sensitive.

michaelleewebb, you need to be in pedantic mode, personally. <smile>

Also, does vba know what 'Integer' means?

[michaelleewebb]

msaccess understands "integer". is 2 bytes long. we have another call "long" is bigger and can contain a higher number. we have "double" for floating point. we also have another one called single i believe, i never use it. "pedantic" mode ?? i had to look that up. am i over reporting ???