"Cardinal-String" zurück in Cardinal: Exception

[ChrisE]

Zitat von Muetze1:

Gleiches Problem hatte ich auch und warum ist ja nun schon gut erklärt worden. Andere Lösung dazu, welche ich damals gefunden habe:

Str() und Val() sind typspezifisch und arbeiten richtig. Grundlegendes Problem hast du nämlich, wenn du eine Zahl die als String vorliegt und > High(Integer) (MaxInt) ist aber auch gleichzeitig < High(Cardinal) ist - diese wird mit StrToInt nicht ordentlich konvertiert und IntToStr64() löst u.U. unerklärlicherweise trotzdem eine ERangeCheck Exception aus (obwohl es eigentlich ohne Problem klappen sollte) (bei eingeschalteter Bereichsprüfung). Die Val() Funktion arbeitet hingegen fehlerfrei und wandelt auch die Zahlen in dem o.g. Bereich sauber in vorzeichenlose 32 Bit Ganzzahlen um. Str() ist auch das passende Gegenstück, welches richtige Zahlen aus Cardinaltypen ohne Vorzeichen mit der richtigen Grösse erstellt.

Danke dir auch. Die Bereichsüberprüfung war bei mir an. Auch Deine Variante Funktioniert auch soweit ich das sehen kann. Das Problem ist, dass ich diese Variationen immer erst auf Maschine A (WinXP / neu / toll / super) erstellen muss und sie dann auf Maschine B (Win98SE / alt / langsam/ sch... ) per USB-Stick rüber "tragen" muss. Hängt aus diversen Gründen nicht am Netz. Delphi darf nicht installiert werden --> Debugging wird suuuuuuuuuuuuuuper. Und da dieser Cardinal ursprünglich ein DWord-Ergebnis von einer Windows-API-Funktion ist (GetWindowThreadProcessId(...)) wird's nochmal besser. Die ProcessID's sind unter XP unterhalb von MaxInt (zumindest bei mir, weil das System nie so lange läuft). Unter W98SE sind die immer > MaxInt. Der Fehler tritt also nur dort auf. Und das ohne Debugging

Zitat von himitsu:

Die Erklärung, warum es "super" klappt ist eigentlich ganz einfach.

Cardinal liegt ja irgendwo im Speicher rum und ist 4 Byte (32 Bit, bei den "aktuellen" 32-Bit-Compilern) groß.
Nun ist es dem Speicher aber vollkommen egal was er ist ... das Was kommt erst zu stande, wenn er intepretiert wird, also wenn irgendwas festlegt was welches Bit zu bedeuten hat und wie diese zusammenarbeiten.

Nun ist allerdings ein Integer auch 4 Byte groß demnach kann man ganz locker diese 4 Byte auch mal als Integer interpretieren, oder auch mal als Single (ist ja auch nur ein 4-Byte-Real-Wert), oder wie wäre es mal als Array[0..3] ob Byte? ... alles was gleich groß ist, kann man direkt umwandeln.
Dieses Integer(C), oder Cardinal(i) macht also nichts anders, als den Inhalt der Veriable umzuwandeln, oder besser gesagt anders zu interpretieren.

Das praktische am Integer und Cardinal ist ja auch noch der Umstand, daß deren Formate eigentlich fast gleich sind ... beim Cardinal wird jedem Bit eine Wertigkeit zugeordnet und diese dann addiert, was beim Integer eigentlich genauso ist, nur daß halt da das höchste Bit nicht als Wert, sondern als das Vorzeichen verwendet wird ... somit macht man alao nur mit Integer(C) das höchste Bit, welches im Cardinal den Bereich über MaxInt darstellt das Vorzeichen, also den Bereich unter MinCardinal.

PS:
öffne einfach mal deinen Windowstaschenrechner, stell den auf Wissenschaftlich um
und gib den Wert für MinInt ein (kannst'e aus der OH kopieren),
dann stell den Taschenrechner auf Hexadezimal um und wieder zurück auf Dezimal ...
und schwupps steht da der Wert für MaxInt + 1,
da dieser Taschenrechner mit 64 Bit rechnet und somit die unteren 4 Bytes sozusagen
als Cardinal gelesen werden, wenn sie aus dem Hexadezimalen kommen.

Danke nochmals für die erklährung. Aber genau diese Tatsache - also die eigentliche gleichwertigkeit von Integer und Cardinal - brachte mich völlig aus dem Konzept bei dem Exception. Ich wollte eben, dass er mir den Inhalt der Wandlung einfach in die Variable schiebt. Doch das lößte immer diesen Exception aus. Naja, jetzt klappt es ja mit dem Typcast.

THX @ all.

und ich meine nicht "Regeln"

[himitsu]

Zitat:

Und da dieser Cardinal ursprünglich ein DWord-Ergebnis von einer Windows-API-Funktion ist (GetWindowThreadProcessId(...)) wird's nochmal besser. Die ProcessID's sind unter XP unterhalb von MaxInt (zumindest bei mir, weil das System nie so lange läuft). Unter W98SE sind die immer > MaxInt. Der Fehler tritt also nur dort auf. Und das ohne Debugging

Also im Grunde hättest du dir auch theortisch die Funktion GetWindowThreadProcessId selbst definieren/einbinden können und statt DWORD einfach LongInt verwenden können ... da wäre dann der TypeCast dann direkt eingebaut ^^

PS: danke für die Info mit den ProcessID's ... hatte micht vor ein paar Tagen auch schonmal gefragt, ob die immer zwischen 0 und MaxInt liegen ... bei mir kommen die ja och nie darüber.
(ich frag mich halt, ob man bei bestimmten Werten ein/zwei Bits einschmugeln kann ... halt nur wenn diese normaler Weise nicht verwendet werde )