passing strings

[ukandrewc]

Hello GedB

I can see that your example should work but it still seems to create a copy of the string.

Ideally I need to manipulate a string in PB, passed by pointer from VB. I can pass the address of a string.

If I use memory functions, then I can confirm that it is the same string, but any attempt to access that memory space with string functions won't work.

I assumed that because you can use pointers in PB you could work like C and have two variables pointing to the same string and manipulate it with both.

I can't use memory functions because the strings are Unicode.

Thanks to all for your help, but I think I'll give this problem a break until I understand PB better.

[tinman]

Hello GedB

I can see that your example should work but it still seems to create a copy of the string.

If you only need to manipulate the string then why not just peek and poke around it? If you end up needing to create a new string to pass back to VB (i.e. your manipulated string becomes longer than the space allocated in your VB program) then you'd need to pass a pointer to the pointer to the string ;)

I think the reason that GedB's example doesn't work is ebcause he returns a string - PureBasic will automatically convert the returned string into a new string, however the value of "Result" within the proceduer will be the same as the string pointer passed in. I think.

[tinman]

There's also code like this which might do what you want without having to use ASM.

Code: Select all

Structure PtrString
    StructureUnion
        *StrPtr.b
        String.s
    EndStructureUnion
EndStructure

Procedure.l AmendString(*str.b)
  DefType.PtrString Result

  Result\StrPtr = *str
  strlen = Len(Result\String)
  For i=0 To strlen/2-1
    temp = PeekB(Result\StrPtr + i)
    PokeB(Result\StrPtr + i, PeekB(Result\StrPtr + strlen - 1 - i))
    PokeB(Result\StrPtr + strlen - 1 - i, temp)
  Next

  ProcedureReturn Result\StrPtr
EndProcedure

foo$ = "blah"
Debug foo$
Debug @foo$
Debug AmendString(@foo$)
Debug foo$
Debug @foo$

A lot of the PB strign functions might return pointers to new strings. If you want your code in VB to see those, you will need to pass the address of the string pointer from VB, or at least pass the new string pointer back (which is what you're doing I guess, what with all the eax stuff).

[ukandrewc]

thanks Tinman, I have tested a few functions in PB for speed.
As PB is faster than VB, I wanted a simple way to pass a pointer to a string and manipulate them.
As you say, the PB compiler appears to cast variables to the correct type which makes it difficult.
Some other basics make this simple, I was hoping for the same from PB.

[GedB]

I can't use memory functions because the strings are Unicode.

PB String functions cannot cope with Unicode either.

[wilbert]

You could use MultiByteToWideChar_ and WideCharToMultiByte_ to convert them or use the string functions from MSVCRT that can handle unicode strings.

[ukandrewc]

PB String functions cannot cope with Unicode either.

They all seem to. Strings passed from VB can be manipulated, parsed into arrays and sorted.

[GedB]

The strings are probably encoded as UTF8.

This means that normal strings are identical to C style strings.

However, if they do contain any extended unicode characters these won't come out right.

[helpy]

PB String functions cannot cope with Unicode either.

They all seem to. Strings passed from VB can be manipulated, parsed into arrays and sorted.

Somewhere in a german forum I found the following information:

VB internally works with Unicode Strings, but if a VB string is passed ByVal to a DLL function, VB creates a temporary copy of the UNICODE string (in ANSI format) and after return from the function call the ANSI string is converted back to UNICODE.

cu, helpy


[edit]
On a microsoft site (at the very end of the article) I found the following:

In brief, the reason is that when VB sees that a string is being passed to an API function, it makes a copy of the array in ANSI format (rather than Unicode) and passes the ANSI version to the function. (For a more detailed discussion of this issue, please see my book.)

[/edit]