PowerBasic String

[Miguel Pando]

Hello Everyone

#COMPILE DLL "TEST.DLL"
DECLARE FUNCTION SysAllocStringByteLen LIB "OLEAUT32.DLL" ALIAS "SysAllocStringByteLen" (psz AS ASCIIZ, BYVAL ulen AS DWORD) AS DWORD
 
'Is this
SUB TEST(ix AS LONG) EXPORT
    ix=SysAllocStringByteLen("Testing......", 16)
END SUB
 
'The equivalent of this
SUB TEST1(s AS STRING) EXPORT
    s="Testing......"
END SUB

Thanks

[Michael Mattias]

More or less, other than with the first example you are responsible for deallocation, and in the second example you are not allocating 16 bytes, and in the first case you will have to assign the return value to a PB-compatible datatype to actually use it. (STRING PTR should work)... and other than the fact that PB string allocation may change without notice.

What are you trying to do or learn?

[Miguel Pando]

A PowerBasic program is calling a function in a DLL written in another language that is returning a pointer to a buffer created with SysAllocStringByteLen.

The PowerBasic program

#COMPILE EXE
DECLARE SUB TEST LIB "TEST.DLL"(s AS STRING)
FUNCTION testit() AS LONG
LOCAL z AS STRING
    TEST z
    MSGBOX z
END FUNCTION

What you are saying is, the PB program is not automatically De-Allocating this buffer. The DLL should do the De-Allocating.

[Michael Mattias]

But if you are replacing the DLL with your own PB-written function, why bother with the SysAllocStringByteLen yourself at all?


IMNSHO*:
Verb-for-verb, statement-for-statement, function-for-function ports from one source code language to another are STONE LOSERS. Always have been. Always will be.


* You may take issue with "IMO" but not with "IMNSHO"

[John Petty]

Miguel
In this case I believe it is the calling programs responsability the deallocate the string space though this is not difficult, in your PB calling program have a decleration like
LOCAL RetStr as STRPTR
After calling the DLL have
RetStr = ReturnedPointer ' first checking of course ReturnedPointer is not NULL
From then on you can handle it just like any normal string except using pointer notation, so to display it, change it. Youwould have for a message box
MSGBOX @RetStr
and to deallocate the space
@RetStr = ""
John

[Miguel Pando]

> But if you are replacing the DLL with your own PB-written function, why bother with
> the SysAllocStringByteLen yourself at all?

I am not replacing the DLL with one of my own. The DLL might be written
by someone else, in any language.

> From then on you can handle it just like any normal string except using pointer notation,
> so to display it, change it. You would have for a message box
> MSGBOX @RetStr

If you write these 2 little programs, you will see that they work fine.
No need to use string pointers. But I am not sure about De-Allocation.


Actually, I am trying to setup a common interface to a DLL written in any language,
by any one, where a PowerBasic compatible string is returned ByRef. Expecting
the caller to automatically De-Allocate the string.
DECLARE SUB TEST LIB "TEST.DLL"(s AS STRING)

If the DLL is written in PB then use
SUB TEST1(s AS STRING) EXPORT
s="Testing......"
END SUB

If not written in basic then use something like this
DECLARE FUNCTION SysAllocStringByteLen LIB "OLEAUT32.DLL" ALIAS _
"SysAllocStringByteLen" (psz AS ASCIIZ, BYVAL ulen AS DWORD) AS DWORD
SUB TEST(ix AS LONG) EXPORT
ix=SysAllocStringByteLen("Testing......", 16)
END SUB

Thanks

[Michael Mattias]

> Expecting the caller to automatically De-Allocate the string.

This may be a not understanding who is the CALL-EE and who is the CALL-ER here but....

That cannot be done "automatically" - the CALL-EE (the function which allocates the string) does not know when the CALL-ER is done with the string, so can never safely de-allocate it until explicitly told to do so. However, the CALL-ER can deallocate it when done with it.

What some libraries which do allocations do is provide and explicit de-allocation function, which the user calls when he is done with the string or other allocated buffer. (example: Malloc and free as used by 'C' language programmers. PB demo here: malloc, realloc, free for PB/Win32 September 20, 2002)

Another way to do it is to make the string "static" in the called proc, and valid only until the next call, at which time it is de-allocated. (that still leaves the 'last' string in memory until the process ends, but that's not a whole lot of waste). That basically means the CALL-ER has to COPY the string returned by the CALL-EE to something he can use in his program before requesting another string allocation.

MCM