PureBasic Forums - English

Sounds nice, but nothing there to play with

What? Sorry, didn't see the link, it really blendes with the rest of the post on this forum.
I didn't expect something visual, you made that clear.


Somehow it doesn't seem to load the css file. I get an IMA at line 118: Debug PeekS(css\debug(".example #test"))
and all the Debug's above are 0 or 0.0

Man the day will come when something I download or copy from this forum will work without problems the first time I try it out, not today, though

No it's not. 5.22 LTS and 5.30 (thanks for reminding me to update my signature....). Same issue in both.

The PB file is the same directory as the .dll, which is one above the css file as per your download as well as the load function css\load("css/style.css") which returns 0 as well, but I don't know if it's supposed to return anything on success.

Perhaps my 32bit system is the issue?

Or is cssload() supposed to have a return value other than zero on success? If yes, is there any way to check why the loading of the file failed?, because it IS in the proper directory, I even used the absolute path to be absolutely sure.

Doesn't do anything, i.e. no "ok".

The following lines cause an IMA as well, after I commented the debug line out.

css\set("@test", "2") <- read error at address 4 (same as the debug line above)
css\set("content", "'this is string nr.'+str(test)") <- at address 4
Debug "size: "+css\size("padding") <- at address 9 (not sure if this info is of any help)

Sadly, I don't have another computer available.
The css is not loaded, that's the problem. But the file or path is not the issue. The object itself doesn't seem to exist.

This should work, shouldn't it? It doesn't

@Derren: IMA with UNICODE compiler mode, try ASCII mode (x86 only).

Danilo wrote:@Derren: IMA with UNICODE compiler mode, try ASCII mode (x86 only).

GEEZ. Thank you...

Man, I really hate this encoding crap we have to deal with all the time. I don't even know where the issue is. I tried saving the css file with Notepad++ as UTF8 and then enabling unicode in PB again and it doesn't work either.

The DLL takes and returns ASCII/UTF8 strings, so it does not work with UNICODE strings directly.

I thought UTF8 is a version of unicode. Maybe not.
But good thing that I know that now and can check it, should it happen again. Would have been bad if I downloaded a .pb file that disabled the unicode compilation and then, when I decided to use the DLL and write a little project from scratch, it would suddenly not work anymore...

Derren wrote:I thought UTF8 is a version of unicode. Maybe not.

UTF8 is a Byte-Encoding compatible to ASCII. It is Byte-based. The smallest character is 1 Byte, and one encoded Unicode-Character
can take 1, 2, 3, or 4 Bytes. Encoded strings do not contain Null/0 chars. One 0-Byte is the end of the string in PB (that's not part of
the UTF8 encoding, that's an API thing, like WinAPI char buffers, that are often terminated by a zero).

Because of the above mentioned similarity/compatibility of UTF8 and ASCII, C programmers (and others) use the same data type char* (Char-Pointer)
when writing DLLs that support UTF8 for strings and char-buffers. The DLL does not support it automatically, it has to be implemented to support UTF8.

With PureBasic's Unicode implementation some things are undocumented. It is based on a Word-Encoding. The smallest character is 1 Word, or 2 Bytes.
It is not documented if PB's Unicode implementation supports (the very old) UCS-2 only, or full UTF-16.
With UCS-2 each character was 1 Word (2 Bytes). In UTF-16 it is called the Basic Multilingual Plane (BMP), and it has support for
many languages already. 65536 characters are not enough to represent all characters in the world, so UTF-16 supports an additional 2-Word-Encoding (like UTF8's Multiple-Byte-Encoding).
An UTF-16 character is usually 16 Bits (1 Word = 2 Bytes). Additional characters are encoded with 32 Bits (2 Words = 4 Bytes).
Two Null/0-Bytes end an Unicode-String in PB, even with extended 2-Word-Encoded UTF-16 characters.

I am not sure if PB supports the full UTF-16 standard, including the 2-Word-Encoding, or if it only supports UCS-2 (UTF-16 Basic Multilingual Plane) on all platforms.
For many languages the BMP is enough (1 Word = 2 Byte = 1 PB Unicode Character), and that's what most of us are using when accessing Unicode-Strings with pointers (*p + sizeof(Character)).
If PB supports the full UTF-16 standard, including the 2-Word-Encoding, the simple *p+sizeof(Character) would be wrong and could lead to problems, if you read input
that contains 2-Word-Encoded characters.

See also:
- Plane (Unicode)
- Comparison of Unicode encodings
- Unicode in Microsoft Windows

- MSDN: Unicode / MSDN: Unicode
- MSDN: Using Unicode Normalization to Represent Strings
- MSDN: Surrogates and Supplementary Characters

- AlanWoord.net/Unicode/
- ShapeCatcher.com - Unicode Fonts
- Fixing Unicode Support in Google Chrome

Wow, complicated. I wonder why they (whoever came up with these encodings) didn't use longs instead of words in the first place. 2^32 different characters should be enough for the forseeable future. Oh well, word documents get 4 times bigger, that would surely be an issue
Now we have 10 different standards instead that are all somewhat compatible until you encounter a hickup. Then you suddenly realize that you missed a bunch of "what stupid format is this string presented in then?" If-blocks...

But SizeOf(Character) returns 1 or 2 depending if the PB source is compiled in Ascii or Unicode, no? So it's not a reliable tool at all to go to the next character in any string. When you read an ascii string, but the program is in unicode, wouldn't it skip every other character and thus ultimately end up outside of the given memory buffer after only half an iteration?
Is this what happened here?

Boy, somebody needs to write an easy tutorial on how to handle strings with all these weird encodings
Or perhaps I should stick to the string functions and hope PB handles all kinds of string correctly instead of plunging into the memory manipulation. Caused me a lot of headaches already...