DLL is returning a number instead of a String

[kpassaur]

I am trying to get a custom DLL to run with MS. Below is the section of Help file that comes with the DLL.

When it loads it is supposed to return a 0 or a 1, instead it actually is returning how many values it has read. However it is not generating any errors.

When it hits the second line it returns a number instead of a String Value

When it hits the third line it retuns a 0 showing it is unloaded.

I am missing something here in what I am doing wrong

Help File

LoadBRW(PChar)
The LoadBRW function takes a String as its argument and will load the borrower filename into a memory buffer so that the fields can be read or manipulated. It returns an integer of 0 if successful or 1 if not. Files are opened in OpenRead or ShareDenyNone in an attempt to compensate for locked files.

UnloadBRW
Simply clears the memory buffer. While the LoadBRW function does overwrite the current buffer, I have found that clearing it on exit in VB prevents memory leaks. This appears to be something particular to VB. It also returns a 0 if everything is ok and 1 if not. (It should never return 1 unless you have some physical problem with the RAM in your computer)

GetFieldByID(Cardinal)
This function is used to retrieve the contents of a specific field as defined in the FieldIDs.xls file that comes with Point. Simply pass an ID to it and you will get back whatever that ID corresponds to in the current memory buffer.

GetFieldByName(PChar)
Using one of the named fields below, you can retrieve the associated value from the buffer currently in memory.


Script

Let>library=C:\Temp\libBRW.dll
LibLoad>library,readbrw

LibFunc>readbrw,LoadBRW,result,C:\Temp\AUT06060.brw
MDL>%result%
LibFunc>readbrw,GetFieldByName,name,Borrower
MDL>%result%%CRLF%%name%

LibFunc>readbrw,UnloadBRW,result3
MDL>%result%%CRLF%%name%%CRLF%%result3%

[Marcus Tettmar]

I'm afraid Macro Scheduler can only work with DLL functions that return integers. It is expecting an integer return value.

It is actually very unusual for DLL functions to return strings unless they are designed for a specific language. Any DLL functions designed for generic use that need to return a string will usually set a pchar buffer passed by reference and return the length of the buffer so that the correct number of characters can be extracted from the buffer. Take a look at the Windows 32 API - this is how all functions that work with strings work. DLLs cannot return strings, only pointers to a memory location that contains a string. Therefore the correct way to work with strings is for the DLL to be passed a string buffer and for it to set that buffer and return the number of characters written to that buffer. Even if you have a DLL that does return a string, you will need some way for it to tell you how many characters were written to the buffer. Otherwise you will run into serious memory issues as you will not know how many characters to read from the buffer. If you read too many, you will get all sorts of horrible outcomes.

If you have access to the code of these DLLs I would recode them to return the length of the string and use a pchar as a parameter passed by reference for the buffer. If you don't have access to the DLLs you may be able to create a DLL wrapper - a DLL with a Macro Scheduler supported function that calls your DLL function in turn, transforming the parameters accordingly. Or we may be able to do this for you. Contact support if you need help with that.

I hope this makes sense.