• Welcome to PlanetSquires Forums.
 

constructor class CWSTR

Started by VANYA, January 25, 2021, 03:22:28 PM

Previous topic - Next topic

VANYA

Hi all!

I don't really understand how the constructor works:

QuoteCONSTRUCTOR CWStr (BYVAL nChars AS UINT, BYVAL bClear AS BOOLEAN)

Constructor should it allocate memory? If so, why does this example show some nonsense for me?

#define UNICODE
#Include Once "AFX/CWSTR.INC"

Function GetDir() As CWSTR Export
Dim sRet As CWSTR = CWSTR(256,TRUE)
? len(sRet) ' why len = 0 ?
GetSystemDirectory(*sRet,256)
Return sRet
End Function

? GetDir() ' of course it's empty here
sleep


If the entry in the code CWSTR(256,TRUE) replaced by WSPACE(256) , then GetDir() returns the value.

José Roca

This constructor pre-allocates memory using FreeBasic's Allocate or CAllocate, depending of the value of  the bClear parameter. It is only useful to minimize memory allocations if you plan to construct a very big string using multiple string concatenations and you know in advance the maximum size of the final string. Initially, the memory is uninitialized (Allocate) or initializated with zeros (CAllocate).

> If the entry in the code CWSTR(256,TRUE) replaced by WSPACE(256) , then GetDir() returns the value.

This is the correct way to use it.

VANYA

I understood everything, thanks. I saw an example in the winapi help and thought the memory is filled like wspace.

José Roca

> I saw an example in the winapi help and thought the memory is filled like wspace.

My bad. I have modified the example in the documentation to:


DIM nLen AS LONG = SendMessageW(hwnd, WM_GETTEXTLENGTH, 0, 0)
DIM cwsText AS CWSTR = WSPACE(nLen + 1)
SendMessageW(hwnd, WM_GETTEXT, nLen + 1, cast(LPARAM, *cwsText))


Sorry.

José Roca

I also have added the following explanation to avoid further confusions:

Quote
The first constructor pre-allocates memory using FreeBasic's Allocate or CAllocate, depending of the value of the bClear parameter. It is only useful to minimize memory allocations if you plan to construct a very big string using multiple string concatenations and you know in advance the maximum size of the final string. Initially, the memory is uninitialized (Allocate) or initializated with zeros (CAllocate).

Writing documentation is the nightmare of a programmer :), specially when English is not his native language.

VANYA

#5
Quote from: José Roca on January 26, 2021, 01:53:11 PM
I have modified the example in the documentation to:

Fine! By the way, I tried the cwstr line in winapi and it is equally picked up by the functions:

dim as CWSTR ws
messagebox(0, ws , ws , 0)
messagebox(0, *ws , *ws , 0)
messagebox(0, **ws , **ws , 0)


all 3 options work.

--------------------------
from the help:
QuoteMID as a function: Something like MID(cws, 2) doesn't work with languages like Russian or Chinese. Using MID(**cws, 2), MID(cws.wstr, 2) or cws.MidChars(2) works.
TRIM, LTRIM, RTRIM, LSET and RSET don't work with languages like Russian or Chinese unless we prepend ** to the variable name.

I don't know how with Chinese characters, but there are no problems with Russian

José Roca

#6
These quirks only apply to older versions of the compiler. In FreeBasic 1.07 it was added the possibility to extend the class from WSTRING and the FreeBasic intrinsic string functions were also modified to work fine with classes like CWSTR. The problem was that in these cases the compiler didn't know that it was dealing with unicode strings and wrongly assumed that they were ansi.

I only had to add


#if __FB_VERSION__ < "1.07.0"
TYPE CWSTR
#else
TYPE CWSTR EXTENDS WSTRING
#endif


and modify a couple of my string function wrappers.

Now CWSTR works with the FreeBasic intrinsic functions and operators as if it was a native data type.

In the documentation i have changed "Quirks" to "Quirks in FreeBasic versions older than 1.07".

BTW I also have provided File Management classes (  https://github.com/JoseRoca/WinFBX/tree/master/docs/File%20Management ) that allow to work with Unicode (FreeBasic native file functions don't allow to use unicode for the file names) and miscellaneous functions like AfxCommand (a unicode replacement for FreeBasic Command).

VANYA

CWSTR is something that, in my opinion, needs to be included in the official delivery of the compiler and fixed in the help. Moreover, it seems to me that such things should take precedence, since they greatly expand the built-in capabilities of the compiler. At the same time, special work is not required, you have already implemented everything. There is really a question about Linux, maybe this is what stops developers.