nderungen in BinaryStream

International Deutsch
1

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.

2

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

3

Danke!
Mal schauen, was mir sonst noch fehlt 


4

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

5

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.

6

Der TextWrangler interpretiert die Bytes. Da muss man schon die DateigrĂ¶ĂŸe schauen.

7

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

b.WriteLong 4

MsgBox str(b.Position)[/code]

-> 4 bytes

8 
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.

9

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

Der Textwrangler hat vielleicht gedacht es wre UTF8 und decodiert.

10

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.

11

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

12

@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.

13

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: Thomas Tempelmann | REALbasic Annoyances

14

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.

15

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.

16

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

17

Solange gibt es ja auch Plugins.

18

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.

19

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

20

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