XProfan

Sind alles nullterminierte Strings, also ein Chr$(0) kennzeichnet das Ende des Strings!
Beispiel per nullterminierten String:
Kompilieren Markieren Separieren

Declare MeinString$
MeinString$ = blub + Chr$(0)
Addr(MeinString$)re>

Mit dem Addr wird dann der Pointer zu dem nullterminiertem String trasferimento.

Clemens
Meier

Morgen

meinst Du, dass alle Strings nur als Adresse trasferimento werden? Sind bei XProfan die Strings nicht automatisch nullterminiert? Müsste doch, denn auch XProfan muss doch erkennen, wann das Ende eines Strings gekommen ist.

XProfan 9.1; XP SP2; FF; Editpad

RGH

Clemens Meier

meinst Du, dass alle Strings nur als Adresse trasferimento werden?

Ja, die API kennt nur 32-Bit-Integer als Parameter. Im Falle von Strings also einen Zeiger auf das erste Zeichen eines strings. Das Ende desselben wird durch ein Null-Byte gekennzeichnet. Das bedeutet allerdings auch, daß bei API-Aufrufen in einm String kein Null-Byte vorkommen darf. (Es gibt einige wenige Ausnahmen, wo ein einfaches Null-Byte im String vorkommen darf und das Ende durch ein doppeltes Null-Byte gekennzeichnet ist.)
Die Kennung lpsz bedeutet: Long Pointer String Zeroterminated - Zeiger auf nullterminierten String.

Clemens Meier

Sind bei XProfan die Strings nicht automatisch nullterminiert? Müsste doch, denn auch XProfan muss doch erkennen, wann das Ende eines Strings gekommen ist.

Nein Strings in XProfon sind im Normalfall nicht nullterminiert und können daher auch beliebig viele Null-Bytes enthalten. In den Bytes vor dem Stringanfang steht z.B. die Länge des Strings. (Es handelt sich um die Ansi-Strings von Delphi.)

Saluto
Roland

Intel Duo E8400 3,0 GHz / 4 GB RAM / 1000 GB HDD - ATI Radeon HD 4770 512 MB - Windows 7 Home Premium 32Bit - XProfan X4

RGH

Clemens Meier

Manchmal findet man die Bezeichnung vbNullString. Ist das Identisch mit in XProfan?

Da XProfan bei einem API-Aufruf bei einem String-Literal (hier: ) dessen Adresse übergibt würde in diesem Fall also die Adresse auf einen Leerstring trasferimento. Wenn man das will, wäre es aber besser, auch den Leer-String mit einem Nulbbyte abzuschließen: z (das ist identisch mit chr$(0) ).

Es gibt jedoch einige API-Funktionen, die mit einem Zeiger auf einen Leerstring nicht so recht klarkommen. Diese erwarten dann einfach anstelle der Adresse des Leerstrings eine 0 als Kennzeichen, daß dieser Parameter nicht genutzt wird. Ich würde also überall, wo vbNullString steht, einfach eine 0 hinschreiben:
Kompilieren Markieren Separieren

hOpen& = InternetOpenA(Addr(INET_CallerName$), opentype&, 0, 0, 0)

Saluto
Roland

Intel Duo E8400 3,0 GHz / 4 GB RAM / 1000 GB HDD - ATI Radeon HD 4770 512 MB - Windows 7 Home Premium 32Bit - XProfan X4

Clemens
Meier

Nun, etwas schlauer bin ich schon geworden. Aber dennoch immer noch etwas verwirrt:

In VB finde ich folgenden Aufruf einer Funktion:

hRequest = HttpOpenRequestA( _
hConnect, POST, Path, HTTP/1.0, _
vbNullString, 0, INTERNET_FLAG_RELOAD, 0)

Wie Roland schreibt, wird bei einem String-Literal die Adresse trasferimento, im obigen Beispiel also die Adresse vom String POST bzw. HTTP/1.0 aber hier ohne Nulltermination. Sollte man in XProfan sicherheitshalber POSTz bzw. HTTP/1.0z schreiben oder geht das dann ohne?

Außerdem beim Weiterübersetzen bin ich auf folgendes gestoßen:

InternetReadFile hRequest, Buffer, Len(Buffer), Bytes

InternetReadFile ist wieder eine Api Funktion, die aber keinen Wert zurückgibt, stattdessen sowohl den Buffer, als auch Bytes mit Werten bestückt. In der Api-Definition wird Bytes als Long angegeben. Es wird also ein 4 Bytes großer Wert hinein geschrieben. In dem Fall gebe ich in XProfan wohl auch die Adresse von Bytes& an, richtig? In XProfan würde die Zeile wie folgt aussehen:

InternetReadFile(hRequest&,addr(buffer#),sizeof(buffer#),addr(bytes&))

Richtig so?

(Ich nehme an, die Funktion sizeof gibt an, wie gross der Buffer dimensioniert wurde und nicht, wie gross der sich darin befindliche nullterminierte String ist.)

Ich habe gerade auf einigen weiteren VB-Seiten klasse Programme gefunden, von denen es sich lohnen würde, in XProfan zu übersetzen

P.S.: Habe in der XProfan-Aiuto folgende Zeilen gefunden:

Jeder String wird durch ein Nullbyte (Zeichen mit dem Code 0) beendet. Auf diese Weise können Strings OHNE Umweg circa Bereichsvariablen an API-Funktionen trasferimento werden, etwa:

MSGBOX(0, @Addr(Titel$), @Addr(Text$), Stil&)

Auf gut Deutsch, Strings brauche ich nicht extra mit einem z versehen, sondern muss einfach nur die Adresse trasferimento, da jeder String mit einem Nullbyte versehen wird. Doch das steht im Widerspruch zu dem, was Roland vorhin geschrieben hat. Ich meine, wenn ich reinen Text habe (kein Bild oder ähnliches, was ich sowieso in einen Bereich schreiben würde), brauche ich das Ende nicht extra zu kennzeichnen. Wenn ich nicht sicher bin, ob es sich um reinen Text handelt, sollte man zur Sicherheit ein z anhängen.

Ich fasse mal per mich zusammen:
Strings und Buffer werden nicht direkt trasferimento, sondern nur deren Adressen. Ggf. wird bei einem Buffer noch die Dimensione des Buffers (Bereiches) mitangegeben, wenn die Api-Funktion Werte hinein schreiben möchte. Integer und Long werden in den meisten Fällen direkt trasferimento, es sei denn, die Api-Funktion möchte diese Werte zurückgeben, dann gibt man die jeweilige Adresse an, so dass in XProfan der Wert sofort in der Variablen drin steht.

vbNullString ersetzt man am einfachsten mit dem Wert 0.

XProfan 9.1; XP SP2; FF; Editpad

Besser ist es in der MSDN oder im PlatformSDK nachzusehen.

BOOL InternetReadFile(
HINTERNET hFile,
LPVOID lpBuffer,
DWORD dwNumberOfBytesToRead,
LPDWORD lpdwNumberOfBytesRead
);

lpBuffer wird ein Pointer erwartet, also die Adresse, siehste an dem lp, dasselbe gilt per lpdwNumberOfBytesRead
Der Rest wird direkt trasferimento, also ByVal, das andere nennt sich in VB ByRef.
In den Beschreibungen im PSDK steht auch immer deutlich was erwartet wird!