Am I missing something here, it doesn’t seem that tricky?
[code] Dim s1 As Text = “A” ’ string works too
Dim s2 As String = “B” ’ text works too
Dim mb1 as MemoryBlock = s1
Dim mb2 as MemoryBlock = “B” ’ can use s2 here instead
Dim mb3 as MemoryBlock
mb3 = mb1 + mb2 ’ concat the two memory blocks
Dim n as Integer
For n = 0 to mb3.Size - 1
system.DebugLog str(mb3.Byte(n)) ’ list bytes
Next[/code]
Ive just re-read the text documentation looking for the obvious thing that I missed, its very clear and well done. I dont think there is anything there to specifically shoot down the not unreasonable assumption that there is a regular clump of data that could be serialized and deserialized without going through an encoding conversion though. Perhaps just saying specifically that text is not a string with embedded style data.
I had originally thought that is what the binaryStream.writeText and binaryStream.readText methods were doing. But it doesnt appear so since a text Encoding must be supplied in order to use them. I question their usefulness in their current incarnation, how can I use writeText when I cant know how many bytes its going to write? without that information I cannot use the readText method. So I would have to convert to a memoryBlock anyway to get the size, so why then would I use writeText rather than just write after I already copied and converted the data into a memoryblock?
If there was an advantage to using writeText then yes, being able to get the length IF it was going to be put into a memoryblock would make that usable. My feeling though is that youd just be walking the data twice then, once to give me the count, and then again when you copied it for writing it out the stream. If I just convert to a memoryBlock then I only walk and copy the data once. But perhaps there are optimizations in writeText and readText? Perhaps they dont copy the data but write directly from your own internal opaque structures and is therefore better because there is no copy?
What is the actual intended usage of writeText and readText when reading requires me to supply the length, yet write does not tell me how many bytes were written? Id need to know that ahead of time anyway since I want to write the length into the stream BEFORE the data 
[quote=268511:@]Am I missing something here, it doesn’t seem that tricky?
[/quote]
That works great on the desktop and other targets, but using the new framework it wont work on iOS. You cant convert between text and memoryblocks that way and it wont add them together that way either, undefined operator. type xojo.Core.MemoryBlock does not define Operator_Add with type xojo.Core.MemoryBlock"
Ahh ok, shame 
Ah, but I see that there already is an Append and remove function for the mutable memory block… That may get me around the problems with concatenation anyway. Still trying to avoid copying too much data, but I think I can work with that!
[quote=268511:@]Am I missing something here, it doesn’t seem that tricky?
[code] Dim s1 As Text = “A” ’ string works too
Dim s2 As String = “B” ’ text works too
Dim mb1 as MemoryBlock = s1
Dim mb2 as MemoryBlock = “B” ’ can use s2 here instead
Dim mb3 as MemoryBlock
mb3 = mb1 + mb2 ’ concat the two memory blocks
Dim n as Integer
For n = 0 to mb3.Size - 1
system.DebugLog str(mb3.Byte(n)) ’ list bytes
Next[/code][/quote]
It’s also worth pointing out that you’re getting an implicit conversion on this line:
Dim mb1 as MemoryBlock = s1Because s1 is of type Text, and you’re using classic framework memoryblocks, it’s actually converting that Text into a String and then into a Memoryblock. So it’s not really the same thing.
[quote=268519:@Greg O’Lone]It’s also worth pointing out that you’re getting an implicit conversion on this line:
Dim mb1 as MemoryBlock = s1Because s1 is of type Text, and you’re using classic framework memoryblocks, it’s actually converting that Text into a String and then into a Memoryblock. So it’s not really the same thing.[/quote]
Good to know, cheers!
I also found working with ascii bytes challenging in a recent project. This can get especially mind bending when the bytes you want to work with are human readable bytes. The classic framework seems to work much more cleanly in that scenario.
I’m not sure what the answer is, but I found the old system of using the “b” version of functions to be very straightforward. I spent hours trying to do some simple byte/text manipulation because I kept running into odd errors. Sometimes compile issues because I wasn’t properly understanding the new framework, sometimes conflicts between trying to mix the old and the new one.
My final solution actually did use both old and new iirc. Now that I think about it, I haven’t even touched Xojo since then. Haven’t really missed it either. I’m afraid Xojo is becoming less enjoyable to use. I understand the need for complexity in some things, but simple things should stay simple IMO.
Let me state the obvious.
’
It would seem to me the method BinaryStream.WriteText could write an undefined (to us) stream of bytes that included a header with length and encoding ands the method could return the bytes written as integer. The Encoding parameter would be optional and when not included, the encoding of the text (Or string - string with no encoding raises exception) would be used
Then BinaryStream.ReadText would not then need a count parameter but the function should return the next position in the steam (or bytes read) as an integer. Again encoding would be optional, and if supplied would convert encoding as needed.
That would at least make transfer between Xojo apps as seemless as possible. For lower level control memory blocks could be used.
Not having any academic training in coding and wanting to be able to get things done as quickly as possible I find the new framework to be less friendly and more intimidating and yes less fun…
Can I master it if I put in the efforts? Sure… But it’s the type of slog that I went with RB to avoid.
[quote=268533:@Karen Atkocius]It would seem to me the method BinaryStream.WriteText could write an undefined (to us) stream of bytes that included a header with length and encoding ands the method could return the bytes written as integer. The Encoding parameter would be optional and when not included, the encoding of the text (Or string - string with no encoding raises exception) would be used
Then BinaryStream.ReadText would not then need a count parameter but the function should return the next position in the steam (or bytes read) as an integer. Again encoding would be optional, and if supplied would convert encoding as needed.[/quote]
That would work fine for files where youre just reading till the end, but it would not work when you need to wrap it in a packet of a known size for sending over a TCP stream or something similar. We really need to be able to get the count of the bytes were about to dump down the stream.
I know you are intimate with this stuff.
Text & encodings isn’t simple.
Representing the “same text” in utf8, utf16, latin1 etc results in different bytes for “the same text”.
The old string type lulled you into a false sense of simplicity that really didn’t exist.
TEXT lets you ignore all that until you absolutely need to dive into things at that level.
To transmit a “text” from one end to the other you need to know how many code points there are (not bytes) and then send that many code points. At the receiving end you need to receive that many code points.
BYTES are a side effect of transmitting code points as Uint32’s or Uint64’s - whichever.
The receiving end needs to know nothing about “encodings” as code points are code points are code points.
But the same code point encoded as ascii, utf8 etc MAY result in different underlying bytes.
Send the code points then.
You already can count how many code points there are (len) and you can send them as whatever type (Uint32 or Uint64) and restore that on the receiving end.
Encodings not required.