See short note about StrPtr:

    StrPtr is used primarily to make efficient UNICODE API calls. In VB4, API calls to a UNICODE function were made with the help of byte arrays:

       Declare Sub MyUnicodeCall Lib "MyUnicodeDll.Dll" _
          (pStr As Byte)

       Sub MakeCall(MyStr As String)
          Dim bTmp() As Byte
          bTmp = MyStr & vbNullChar
          MyUnicodeCall bTmp(0)
          MyStr = bTmp
          MyStr = Left$(MyStr, Len(MyStr - 1))
       End Sub

    Clearly, the amount of work to simply pass a NULL terminated UNICODE string and return its value into the original string is totally unacceptable. By the time correct handling of the terminating NULL character is included, No less than 4 copies of the string are required.

    With StrPtr, this code reduces to:

       Declare Sub MyUnicodeCall Lib "MyUnicodeDll.Dll" _
          (ByVal pStr As Long)

       Sub MakeCall(MyStr As String)
          MyUnicodeCall StrPtr(MyStr)
       End Sub

    VarPtr/StrPtr/ObjPtr are all very, very fast, so the overhead to call a UNICODE function is now actually lower than calling the corresponding ANSI function because no conversion is required.

    StrPtr can also be used to optimize ANSI declare calls. Instead of passing the same string variable multiple times to a declare function and incurring the conversion overhead for each call, use the StrConv function once and StrPtr in each call:

       Declare Sub MyAnsiCall Lib "MyAnsiDll.Dll" _
          (ByVal pStr As String)

       MyAnsiCall MyStr

    becomes:

       Declare Sub MyAnsiCall Lib "MyAnsiDll.Dll" _
          (ByVal pStr As Long)

       MyStr = StrConv(MyStr, vbFromUnicode)
       MyAnsiCall StrPtr(MyStr)
       MyStr = StrConv(MyStr, vbUnicode) ' Not always required

    StrPtr is also the only way to tell the different between an empty string ("") and a null string (vbNullString). StrPtr(vbNullString) returns 0, while StrPtr("") is non-zero.

From http://vb.mvps.org/tips/varptr.asp

There are a whole list of unsupported things from VB - LibreOffice does not in fact support Visual Basic - we recommend users transition to Basic or Python which are supported.

That being said I am closing this as NOTABUG - don't worry though we are well aware that VB is currently not supported and maybe at some point in the future we'll fully implement VB support, this bug report isn't necessary to remind the developers that VB currently is lacking.

Thanks for your understanding, feel free to ping the user list if you need help transitioning away from VB.

PS I know that "NOTABUG" is a bit misleading as this was an enhancement request - it's more "we are aware of the lacking functionality with VB and it's been reported many times before so leaving this particular bug open isn't going to help anyone"

(In reply to Anton Kochkov from comment #1)
> See short note about StrPtr:
> 
>     StrPtr is used primarily to make efficient UNICODE API calls. In VB4,
> API calls to a UNICODE function were made with the help of byte arrays:
> 
>        Declare Sub MyUnicodeCall Lib "MyUnicodeDll.Dll" _
>           (pStr As Byte)
> 
>        Sub MakeCall(MyStr As String)
>           Dim bTmp() As Byte
>           bTmp = MyStr & vbNullChar
>           MyUnicodeCall bTmp(0)
>           MyStr = bTmp
>           MyStr = Left$(MyStr, Len(MyStr - 1))
>        End Sub
> 
>     Clearly, the amount of work to simply pass a NULL terminated UNICODE
> string and return its value into the original string is totally
> unacceptable. By the time correct handling of the terminating NULL character
> is included, No less than 4 copies of the string are required.
> 
>     With StrPtr, this code reduces to:
> 
>        Declare Sub MyUnicodeCall Lib "MyUnicodeDll.Dll" _
>           (ByVal pStr As Long)
> 
>        Sub MakeCall(MyStr As String)
>           MyUnicodeCall StrPtr(MyStr)
>        End Sub
> 
>     VarPtr/StrPtr/ObjPtr are all very, very fast, so the overhead to call a
> UNICODE function is now actually lower than calling the corresponding ANSI
> function because no conversion is required.
> 
>     StrPtr can also be used to optimize ANSI declare calls. Instead of
> passing the same string variable multiple times to a declare function and
> incurring the conversion overhead for each call, use the StrConv function
> once and StrPtr in each call:
> 
>        Declare Sub MyAnsiCall Lib "MyAnsiDll.Dll" _
>           (ByVal pStr As String)
> 
>        MyAnsiCall MyStr
> 
>     becomes:
> 
>        Declare Sub MyAnsiCall Lib "MyAnsiDll.Dll" _
>           (ByVal pStr As Long)
> 
>        MyStr = StrConv(MyStr, vbFromUnicode)
>        MyAnsiCall StrPtr(MyStr)
>        MyStr = StrConv(MyStr, vbUnicode) ' Not always required
> 
>     StrPtr is also the only way to tell the different between an empty
> string ("") and a null string (vbNullString). StrPtr(vbNullString) returns
> 0, while StrPtr("") is non-zero.
> 
> From http://vb.mvps.org/tips/varptr.asp

This explanation really highlights why StrPtr was such a game-changer for VB developers working with Unicode APIs. The old byte-array approach wasn’t just verbose, it introduced unnecessary memory copies, performance overhead, and a higher risk of subtle bugs around null-termination and string length handling. Using StrPtr directly avoids all of that by passing a pointer to the internal Unicode buffer, which is exactly what most Unicode APIs expect.

That said, one important thing for developers to remember is that StrPtr should only be used when the API explicitly expects a pointer to a Unicode string and does not attempt to reallocate or persist the pointer beyond the call. Since VB strings are managed by the runtime, passing the pointer to APIs that modify buffer size or store the pointer can lead to crashes or memory corruption. Pairing StrPtr with proper ByVal declarations and understanding API ownership rules is critical.

The same performance logic applies when optimizing ANSI calls — doing a single StrConv and reusing StrPtr avoids repeated conversions and can significantly reduce overhead in tight loops or high-frequency API calls. Topics like this are a great reminder that understanding what’s happening under the hood often matters more than just getting code to “work.” I’ve seen similar deep-dive discussions around memory handling, performance trade-offs, and legacy language interoperability explained clearly on https://zonelify.com/ which is helpful when dealing with lower-level concepts like pointers and runtime behavior.