José´s WinFBX Framework is an optional but recommended part of my IDE. He generously allowed me to extract the dynamic unicode string part for use in my IDE, in case people wouldn´t want to include WinFBX. This is basically the same what DWSTRING.bi contains.
I can confirm that it is working as "advertised" - no bugs so far. The only (in my view acceptable) drawback is, that in some cases fbc doesn´t accept the "CWstr/DWSTRING/USTRING" (whatever you name it) type as string type (In some other cases it does!). Therefore you have to prepend a "*" to variable names in these cases. This is a problem with FreeBASIC not consistently handling types and not a problem of José´s code. I can say that, because i tried myself to fiddle around with his code and had discussions with him about the code. But in the end i had to admit, that, what he found, is the best possible under the given circumstances.
kcvinu wrote:When will they add this CWSTR and DWSTR into freebasic core ? After all, these data types are essential for a language.
I agree that such datatypes should be part of freebasic core, but there are a few issues that prevents to use this implementation. First, it is Windows-only while FreeBasic aims at providing a cross-platform development environment. Second, the FB runtime is currently implemented in C (although there exists an attempt to reimplement it in FB) and deeply integrated in the compiler - quite some additional work would be necessary to integrate this in the compiler and extend all built-in methods accepting these additional string types.
@St_W,
Thanks for the reply.
There is a language called Nim. (formerly Nimrod). It is compiled to C. They also targeting to Linux, Windows, and Mac. In Nim, a normal string data type is dynamic UNICODE string.
Well, i didn´t have time for inspecting the compiler code thoroughly enough, but i think it would be enough to add "DWSTRING" (and maybe other clones of it) to the known string types, other changes and adaptions shouldn´t be necessary. Internally a DWSTRING is a WSTRING, which the compiler already supports, the DWSTRING type supplies the memory mangement ensuring the buffer size meets the required size (... a dynamic WSTRING). While in some cases the compiler accepts a DWSTRING without any problem, in some others cases it rejects it ("type mismatch"), because it doesn´t recoognize, that it´s in fact a WSTRING.
The current workaround for places, where the compiler doesn´t accept it, is to return a DWSTRING as "content of WSTRING PTR" (which is in effect a WSTRING)
As for the mulitplatform problem: the C-Runtime functions implemented in DWSTRING (e.g wmemmove) could be replaced by universal functions - which is quite some work to do, but possible.
But it failed. Then I found that there is an operator " * ". And everything worked perfectly. What prompted you to use " * " operator instead of "@" operator?
1. Because @ is needed to get the address of the class. Otherwise, we could not pass a pointer to the class to another procedure.
2. Because in older versions of the compiler before 1.07 it was necessary to use * and ** to workaround a quirk of the compiler when working with statements like LTRIM, RTRIM and others. This was solved when the possibility to extend the class from WSTRING was added in 1.07. The code in this thread was posted before that change and would need to add
@Josep Roca
Got it. Thanks for the reply. :)
This library is very useful to me. All of my free basic projects are Unicode based. So I use W letter win api functions. They need LPCWSTR type parameter and DWSTRING is perfect for it. I don't know how to express my gratitude. BTW, All your libraries are a treasure for beginners like me. I know that there are lot of knowledge hidden inside http://www.jose.it-berater.org/smfforum/index.php
Edit------------
Is there any difference in CWstr & DWSTRING ?
The only differences are internal, but usage is the same.
As I posted in one of the earlier posts:
If you're using WinFBX, you can use CWSTR instead of DWSTRING and the AfxStr functions instead of the DWStr ones. I have posted these variations to make them independent of my framework so that FBer's not wanting to use it for whatever reason can at least use unicode with Windows easily. I even have used the .bi extension instead of .inc to avoid rejections :)
If you're using WinFBX, you can use CWSTR instead of DWSTRING and the AfxStr functions instead of the DWStr ones. I have posted these variations to make them independent of my framework so that FBer's not wanting to use it for whatever reason can at least use unicode with Windows easily. I even have used the .bi extension instead of .inc to avoid rejections :)
That's a good point. Since everyone wants independent libs in their code. So this is very handy for all. And I think it's not good to bloat our code with not-needed libs. I've heard that Some languages will only choose the required code from a big include file. I don't know how fbc works in this case.
> And I think it's not good to bloat our code with not-needed libs. I've heard that Some languages will only choose the required code from a big include file. I don't know how fbc works in this case.
This is why WinFBX does not use libraries, but source code, and every method in the classes and every function if prefixed with the keyword PRIVATE. This way, unused methods and functions aren't included in the executable, avoiding bloat. See this thread (second method) viewtopic.php?f=9&t=26728