I am going through my project and updating the code to API 2.0. It incorporates Kem’s Kaju Updater, and one of the functions included is
[code]Public Function ContentsOf(zipFile As FolderItem) as String
// Gets the contents of a the given zip file.
// For this purpose, assumes that there is only one main item within the
// file.
sh.Execute( cmd )
Var result as string = sh.Result
result = ReplaceLineEndings( result, EndOfLine.UNIX )
result = result.NthFieldB( EndOfLine.UNIX, 1 )
if result.Right( kPathSep.Length ) = kPathSep then
result = result.Left( result.Length - kPathSep.Length )
end if
return result
End Function
[/code]
NthFieldB is deprecated. The Xojo Documentation says to replace it with MemoryBlock - but doesn’t explain how you would do that. The Xojo IDE suggests using String.SplitBytes instead. If I alter the code like this:
sh.Execute( cmd )
Var result as string = sh.Result
'result = ReplaceLineEndings( result, EndOfLine.UNIX )
result = result.ReplaceLineEndings(EndOfLine.UNIX)
'result = result.NthFieldB( EndOfLine.UNIX, 1 )
Var lines() As String
lines = result.SplitBytes( EndOfLine.UNIX )
result = lines(0)
Would that be functionally equivalent to the original?
Thanks.
I think so…
But why do you need the byte wise function here? EOL will work with strings text functions.
That said if there is not an API 2 Equivalent to NthField B already, there should be.
What if you had 10000+ lines … Then doing it that way becomes very wasteful of system resources (as would copying the whole string to a memoryblock)
They originally tried to force us to do all byte type stuff in MemoryBlocks by copying strings there (a la the xojo.framework) but people pointed out situations where it was not practical so they were forced to relent on that somewhat… But I get the feeling they really did not want to even though it obvious is lightest way to do it
NthFieldB was added to the language because there was a need for some cases… and those needs still exist. We still have string/binary duality… and that is a GOOD thing for performance given string immutability.
Thanks for the reply. I’m not sure why NthFieldB was used rather than NthField. Binary vs string is still not not an area that I have a good grasp of yet. There were a few instances in Kaju Updater where InstrB, MidB etc were used also but at least they have direct replacements in API 2.0.