nderungen in BinaryStream

Ich wollte mir mal wieder das aktuelle Xojo ansehen und schauen, wie sich meine Anwendung verhlt.
Da ich derzeit noch immer mit RS010r1 arbeite, bin ich es gewohnt, dass ich einiges anpassen muss. Anscheinend ist mal wieder etwas hinzugekommen :frowning:

BinaryStream kennt WriteLong, ReadLong, etc nicht mehr.

Gibt es eine “bersetzungsmatrix”? Sprich, was wird jetzt dafr als Ersatz angeboten?

Gru, Stefan Mettenbrink.

WriteLong => WriteInt64
ReadLong => ReadInt64
WriteByte => WriteUInt8
ReadByte => ReadUInt8
WriteShort => WriteInt16
ReadShort => ReadInt16

Danke!
Mal schauen, was mir sonst noch fehlt …

Schau nochmal nach, ob WriteLong ein 32 oder 64bit Integer war!

Hmmm…
Ich habe mal in der Sprachreferenz von REALstudio 2010r1 nachgesehen. Da gibt es WriteLong auch schon nicht mehr (wird im Code aber nicht bemngelt und beim automatischen Vervollstndigen angeboten). Ist das noch aus Zeiten von REALbasic 3.0 oder 3.5?

Merkwrdig.
Ich habe folgenden Code getestet (RS2010):
Dim WriteToFile as BinaryStream
Dim f as FolderItem
f=GetSaveFolderItem("","")
If f <> Nil Then
WriteToFile=BinaryStream.Create(f,true)

WriteToFile.WriteLong &h0

WriteToFile.close

End If

Das Ergebnis habe ich mir in TextWrangler angesehen (Hex Dump Front Document) und erhalte:
0000: 00 00 00 00 00 00 00 00

Soweit hatte ich es erwartet. Nun eine kleine nderung:
WriteToFile.WriteLong &hFFFFFFFF

Ich erhalte in TextWrangler:
0000: C7 02 C7 02 C7 02 C7 02

Warum nicht:
0000: FF FF FF FF FF

Ich bin verwirrt!
Wie bekomme nun heraus, ob ich WriteInt64 oder WriteInt32 nehemen sollte?

Gru, Stefan Mettenbrink.

Der TextWrangler interpretiert die Bytes. Da muss man schon die Dateigröße schauen.

[code] dim m as new MemoryBlock(0)
dim b as new BinaryStream(m)

b.WriteLong 4

MsgBox str(b.Position)[/code]

-> 4 bytes

WriteToFile.WriteLong &hFFFFFFFFFFFFFFFF
 MsgBox str(WriteToFile.Position)

Ergibt bei mir auch 4 Bytes.
Warum meckert RS nicht schon bei dem viel zu groem Wert?
&hFFFFFFFFFFFFFFFF sind fr mich 16 Bytes.
Warum der TextWrangler bei einem Hex Dump berhaupt etwas interpretiert, ist mir ebenso ein Rtsel.

Auch wenn ich etwas verwirrt bin, hatte ich eigentlich ohnehin 32 Bit erwartet, da ich eigentlich berall nur Interger-Werte damit sichere. Die sollten in RS (IMHO) immer 32 Bit haben.

Gru, Stefan Mettenbrink.

&hFFFFFFFFFFFFFFFF wre ja ein UInt64.
Aber WriteLong nimmt nur ein Integer, als wird gekrzt.

Der Textwrangler hat vielleicht gedacht es wre UTF8 und decodiert.

Hmm… OK.
Ich habe meinen Code in Xojo gerade auf .WriteInt32 gendert. Danke!

Jetzt habe ich noch ein altes ZIPCompress_class, welches ReadShort nutzt. Da muss ich mal scheun, ob es etwas aktuelles gibt oder ob ich es rauswerfen kann.

Gru, Stefan Mettenbrink.

Zum Ansehen von Hex-Daten solltest Du einen Hex-Viewer nehmen (0xEd oder hnliches). WriteLong ist garantiert WriteInt64. Auch schon 2010!

@Beatrix Willius für doch mal das Codebeispiel von mir aus mit altem Real Studio. 4 Bytes. Damals war Short = 2 und Long = 4 bytes.

Der Compiler sieht den Wert als -1 an, und den kann er dann munte rauf alle signed-Typen, von Int8 bis Int64 zuweisen.

Siehe auch: http://www.tempel.org/RB/Annoyances

Jain.

Die Regel ist auch bei einigen anderen Sprachen so, wie etwas lower-level sind: Integer-Größe entspricht der von Pointern. Also 4 Byte 32 Bit-Builds und 8 Byte bei 64 Bit-Builds.
Das ist so gemacht, weil z.B. das OS (wie OSX) das auch so will, denn es übergibt dann auch allerlei Parameter in der “nativen” Größe. D.h, wenn man Declares macht, kann man überall “Integer” drin lassen, weil die Parameter sich dann von 32 auf 64 Bit mit anpassen.
Blöde wird’s bei Strukturen, wie man sie z.B. braucht, wenn man Libs aufruft oder MemoryBlocks dafür benutzt. Da muß man dann teils ganz schon Arbeit reinstecken. Für meine Zip-Klassen war das z.B. nötig, um die zlib-Funktionen richtig unter 64 Bit zu nutzen.

Um es abschlieend aufzuklren:
Ich habe ursprnglich Int64 eingesetzt. Nach den Empfehlungen hier und meinen Versuchen war ich von Int32 berzeugt und habe WriteInt64 durch WriteInt32 ersetzt. Da ich dasselbe fr Read vergessen hatte, kam dann beim ersten Versuch dann das Ergebnis. Die eingelesenen Schleifenzhler waren zu gro.

Fazit: In meinem Fall (.WriteLong und .ReadLong ind REALstudio 2010r1) ist eine Konvertierung in WriteInt32 bzw ReadInt32 richtig gewesen.

BTW, wird es eine 64-Bit Version von Deinen ZipFolderItem-Klassen (mit Wegfall der 4GB Beschrnkung fr Dateien) geben?

Gru, Stefan Mettenbrink.

Erst, wenn ich es selbst brauche. Ich verdiene nicht genug mit dem Verkauf der Klassen allein, um den Aufwand zu rechtfertigen.

Solange gibt es ja auch Plugins.

Ich habe in letzter Zeit nicht danach gesucht, fand die ZipFolderItem-Klassen aber seinerzeit gut, da ich sie wie FolderItems nutzen konnte.
Gibt es da ein Plugin, das mit Dateigrößen über 4GB zurecht kommt und ähnlich einfach in der Nutzung ist?

Gruß, Stefan Mettenbrink.

Schau’s dir mal an.

Aus meiner Sicht recht einfach zu benutzen:

http://monkeybreadsoftware.net/class-zipmbs.shtml
und
http://monkeybreadsoftware.net/class-unzipmbs.shtml

Danke für den Hinweis.
Ich lege das mal auf die ToDo-Liste.
Gruß, Stefan Mettenbrink.