Hey, does anybody know if there is a replacement in the new Xojo-Framework for the Text Datatype of the String Method ReplaceAllB?
There is an additional parameter on Replace and ReplaceAll.
It would not make any sense, since Text is by essence not a bucket of bytes, as string is. Text type simply cannot be binary.
Convert the text to string, do the ReplaceAllB and then try to put the string back in to text… It’s what I needed to do to keep old code from breaking new code…
Why use Text at all then?
In iOS, there is no string at all, and no ReplaceAllB.
But if I may ask, why is ReplaceAllB required ?
[quote=367870:@Michel Bujardet]In iOS, there is no string at all, and no ReplaceAllB.
But if I may ask, why is ReplaceAllB required ?[/quote]
Speed. For example if you deal with (sometimes gigabytes of) sequence data (consisting of A G C T N R Y M W S K B D H V) then it is MUCH faster than ReplaceAll and nearly as fast as memoryblocks.
I understand the difference. My question was more “Why is ReplaceAllB required with Text ?”. In other platforms, it is pretty easy to use a string instead.
In iOS the choice simply does not exist, so maybe it is possible to do without binary. But only the OP knows the intent.
SSLSocket still uses String, but I’m trying to use all the new framework for code, so switched it to Text for use within the program…
Yes, but the data that comes in from an SSLSocket (any socket for that matter) has no Encoding and cannot be coerced into a Text without setting the Encoding. Once youve done that, ReplaceAllB is meaningless.
If you really want to use the new framework for this use a Xojo.Core.MutableMemoryblock and use IndexOf to do the searches and then set the bytes yourself using the CStringValue or Mid methods.
Sorry for delay. I was looking for ReplaceAllB for the new Framework because I have to search and replace a specific catalog of various bytes/letters. Some letters based on one byte, others on two or three. For now, the Text Datatype has an encoding for each Letter, but i have to check the bytes.
Greg OLones Description sounds good. Im not a profi. Does a MutableMemoryBlock change the original file? I dont want that. I only need the converted Data. And could you please give an example, how to do such anreplace für an UTF-16 file? For example search for &h1EA1 and replace it with &hF261.
Thanks.
A MemoryBlock (any MemoryBlock) is a contiguous chunk of memory that holds a series of bytes. In the classic MemoryBlock or the new MutableMemoryBlock, you can manipulate those bytes directly in place, but when reading from a source, it’s a copy of that source.
Think of a Picture that is read from a file. You can change the colors in that Picture or even replace it with something entirely different, but it has nothing to do with the original file until you decide to write it back.
If the original data is UTF-16 encoded, it means you are dealing with text, not bytes, so the process would be to read it as Text and convert that to a MemoryBlock as UTF32 for convenience.
For your replace, you would create new MemoryBlocks from the code points you are looking for, then use IndexOf to locate the bytes and Mid to replace them.
For example…
dim mb as new Xojo.Core.MutableMemoryBlock( _
Xojo.Core.TextEncoding.UTF32.ConvertTextToData( myText ) )
dim findThis as Xojo.Core.MemoryBlock =
Xojo.Core.TextEncoding.UTF32.ConvertTextToData( &u1EA1 )
dim replaceWith as Xojo.Core.MemoryBlock = _
Xojo.Core.TextEncoding.UTF32.ConvertTextToData( &uF261 )
dim pos as UInteger = mb.IndexOf( 0, findThis )
mb.Mid( pos, replaceWith.Size ) = replaceWith(Not tested.)
Why UTF32? Because every character will be represented by four bytes all the time so it won’t matter if you replace, say, &u0041 with &uF261.
BTW, this is incorrect. The Text type has no encoding at all, it’s the actual text. In other words, it’s the end result of what you’d get after applying encoding to a series of bytes. Think of it more as an array of Unicode code points.
You should stay safely with String. Using Text + Xojo.Core.MutableMemoryBlock is WAY more complex. Keep it simple, damn…