Announcement

Collapse
No announcement yet.

PowerBasic String

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

  • Michael Mattias
    replied
    > 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

    Leave a comment:


  • Miguel Pando
    replied
    > 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

    Leave a comment:


  • John Petty
    replied
    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

    Leave a comment:


  • Michael Mattias
    replied
    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"

    Leave a comment:


  • Miguel Pando
    replied
    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
    Code:
    #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.

    Leave a comment:


  • Michael Mattias
    replied
    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?

    Leave a comment:


  • Miguel Pando
    started a topic PowerBasic String

    PowerBasic String

    Hello Everyone

    Code:
    #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
Working...
X