Bug 81123 - StrPtr - unsupported function (BASIC Runtime Error '35')
Summary: StrPtr - unsupported function (BASIC Runtime Error '35')
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: BASIC (show other bugs)
(earliest affected) rc
Hardware: Other All
: medium enhancement
Assignee: Not Assigned
Depends on:
Reported: 2014-07-09 17:44 UTC by Anton Kochkov
Modified: 2014-07-20 05:18 UTC (History)
1 user (show)

See Also:
Crash report or crash signature:


Note You need to log in before you can comment on or make changes to this bug.
Description Anton Kochkov 2014-07-09 17:44:32 UTC
For example in this line:

nRet = WideCharToMultiByte(GlobalEncoding, 0, StrPtr(Data), ccLen, ByVal 0&, 0, 0, 0)
Comment 1 Anton Kochkov 2014-07-09 17:47:15 UTC
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


       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
Comment 2 Joel Madero 2014-07-20 05:18:00 UTC
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.
Comment 3 Joel Madero 2014-07-20 05:18:50 UTC
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"