Hexwert wird falsch ausgewertet

[DatenDuck]

Hallo Leute,

ich hänge an etwas seltsamen...

Wenn ich die folgende Konstante

Const HEADERTYPE_5 = &H00008000   

verwende, hat sie den Wert -32768 ??

8000 Hexadezimal, sind jedoch nach meiner Berechnung 32768 Dezimal?!?!?
Der Witz ist leider der, dass ich genau die positiven 32768 benötige.

Ich weiss, ich könnt auch gleich den richtigen Wert zuweisen, aber ich bin nunmal darüber gestolpert... 
Vielleicht hat ja jemand 'ne Erklärung hierfür.

ARGS... Nachtrag... Also... Ich habe der Konstante mal direkt den Wert 32768 zugewiesen, also

Const HEADERTYPE_5 = 32768

und trotzdem ist der Wert am Ende -32768...
Ab genau dieser Grenze ist's mit Integer vorbei und long muss her... Gibt's da Probleme??

Vielen Dank schonmal für die Hilfe!



Und noch ein Nachträgchen... Im Verlauf des Codes werden noch andere Konstanten mit Hex Werten befüllt.
Ich dachte zwischenzeitlich, dass es vielleicht einfach an der Tatsache liegt DASS ich Werte als Hex zuweise...
Aber in meinem Minitest:
Sub Click(Source As Button)
   Const schrott = &H00001000   
   Const zahl = 32768
   
   Msgbox zahl
End Sub

ist "Zahl" wiederum leider positiv


Und nochwas:
Wenn ich die Konstante so deklariere:
Const zahl = &H00001000&
Wirds'n positiver und richtiger Wert... Aber durch das & am Ende zwinge ich Notes ja einen Double zu nehmen und lass es nicht mehr selber entscheiden...


Vielen Dank nach wie vor für die Hilfe 
Bis dann,
-Moritz

[Semeaphoros]

Aus der Hilfe:

An Integer value is a whole number in the range -32768 to 32767, inclusive.

Heisst, wenn man zu einem int-Wert 32767 eines dazu zählt, ist die nächste Zahl -32768 .......

Wenn Du das Ding positiv haben musst, dann verwende Long, anders geht es nicht.

[DatenDuck]

Die Hilfe zu "Const" sagt jedoch folgendes:
If you do not append a data type suffix character to constName or expr, LotusScript determines the data type of the constant by the value assigned to it.


Const sollte also selber checken was Sache ist!

Bugge ich, oder bugt LS?

[koehlerbv]

Aber der LS-Interpreter tut das doch, Moritz. Und ganz brav nimmt er hierfür den platzsparendsten Datentyp, der zur Verfügung steht. Hex 8000 ist in Integer -32768, das passt also gerade noch rein, und Du hast nix anderes angeordnet - und flutscht, hast Du den "passenden" Datentyp mit (bei Dir) unpassendem Wert.

Aus meiner Sicht: Works as designed.

Bernhard

[Semeaphoros]

Jo, Bernhard hats genau in dem Moment gesagt, 8000H passt genau in 2 Bytes und ist damit ein passender Integer-Wert .... Du wirst das feststellen können, wenn Du mit Hex$ zurückvewandelst.

[DatenDuck]

OH man... Ich bin von einem Fluch belegt... Jede Sache die ich mir kaufe ist in der ersten Version in irgend einer Form defekt...
Und jetzt kommt dieser Pfrimelfehler.. Wieso muss es auch unbeding DIESER eine Wert sein... Dumme Sucherei war das... Naja Schicksal... Aber danke für die Hilfe...

[Semeaphoros]

Sei nicht so stolz auf diesen Wert ... jeder Wert zwischen 8000H und 8FFFH würde als negative Integer-Zahl interpretiert.

[DatenDuck]

Naja... Stolz.. 

Zahlenhandhabe ist nicht mein Gebiet...
Der LS Interpreter zählt also in Hex von 8000h bis FFFFh aufwärts, übertragen auf Integer von -32768 auf -1 abwärts.
Ist das eine Eigenschaft des LS Interpreters oder wird das generell so gemacht?

[m3]

http://de.wikipedia.org/wiki/Zweierkomplement

[DatenDuck]

Uff... Stimmt... Da war was.... In der Berufsschule...
Wunderbar.. mal wieder mit nem Thread blamiert... Ze fix 

[Semeaphoros]

Der LS Interpreter zählt also in Hex von 8000h bis FFFFh aufwärts, übertragen auf Integer von -32768 auf -1 abwärts.

Aufwärts, mein lieber, aufwärts ..... -32768 ist deutlich kleiner als -1

Ist das eine Eigenschaft des LS Interpreters oder wird das generell so gemacht?

Siehe Martins Link, der Professor macht das schon intern so.

[DatenDuck]

Aufwärts, mein lieber, aufwärts .....

Du sagst es...