Invalid_handle_value

[Alexander I]

Hallo,

ich habe ein Program das ich einmal mit Delphi6 und einmal mit XE5 compiliere.

Es geht um folgende Programmzeilen:

Delphi-Quellcode:

  TCOM = class(TObject)//(TComponent)
  private
    FHandle: Cardinal;
  public
    constructor Create;//(AOwner: TComponent); override;
  end;

implementation

constructor TCOM.Create;//(AOwner: TComponent);
begin
 FHandle := INVALID_HANDLE_VALUE; 
//   Min cardinal value = 0
//   Max cardinal value = 4294967295
end;

Bei Delphi6 ist INVALID_HANDLE_VALUE = 4294967295. Hat also den Maximalwert von Cardinal.
In XE5 ist INVALID_HANDLE_VALUE = 18446744073709551615.

Wieso der hohe Wert bei INVALID_HANDLE_VALUE in XE5?

Nach der Übergabe besitzt FHandle den Wert 4294967295 in XE5.

Danke und Gruß.

[freimatz]

Hm ...
Ich habe eine Vermutung, aber warum schaust nicht die Deklaration von INVALID_HANDLE_VALUE an

[Bernhard Geyer]

Wenn du einen Handle verwendest solltet du THandle als Typ verwenden.

[Der schöne Günther]

Gib doch mal 18446744073709551615 bei der Suchmaschine deines Vertrauens ein, vielleicht kommst du dann drauf ;-)

[Alexander I]

Ist der Grund der Unterschied der Compilierung auf 32bit und 64bit System?

[EWeiss]

Zitat:

Wenn du einen Handle verwendest solltet du THandle als Typ verwenden.

Oder
FHandle : HWND

kommt auf das gleiche raus.

gruss

[Der schöne Günther]

Zitat:

Zitat von Alexander I (Beitrag 1360516)

Ist der Grund der Unterschied der Compilierung auf 32bit und 64bit System?

Ganz genau das. Aus genau dem Grund sollte man THandle als Datentyp nehmen. Unter Windows haben Dinge wie ComPort-Handles nicht mehr 32, sondern 64 Bit. Cardinal ist allerdings immer 32 Bit. THandle nicht, das ist entweder 32 oder 64 Bit, je nach Plattform.

Zitat:

Zitat von EWeiss (Beitrag 1360517)

Oder
FHandle : HWND
kommt auf das gleiche raus.

Es gibt keinen einzigen Grund weshalb man ein CreateFile-Handle in ein HWND ablegen sollte.

[EWeiss]

Zitat:

Es gibt keinen einzigen Grund weshalb man ein CreateFile-Handle in ein HWND ablegen sollte.

Klar weil es für HWND uninteressant ist ob 32 oder 64 Bit Anwendung.
Ich verwende grundsätzlich kein THandle. (Das ist wieder so ein Delphi Ding.)

Aber du kannst es ja machen wie du willst.
Es sei denn ich habe den Zusammenhang nicht richtig verstanden.. Dann sei's so.

In einem jedoch hast du recht ein ungültiges HWND kann nicht mit INVALID_HANDLE_VALUE verglichen werden.
Dafür wäre dann IsWindow(myHWND) zuständig.

gruss

[Alexander I]

Danke.

[Zacherl]

Zitat:

Zitat von EWeiss (Beitrag 1360520)

Zitat:

Es gibt keinen einzigen Grund weshalb man ein CreateFile-Handle in ein HWND ablegen sollte.

Klar weil es für HWND uninteressant ist ob 32 oder 64 Bit Anwendung.
Ich verwende grundsätzlich kein THandle. (Das ist wieder so ein Delphi Ding.)

Aber du kannst es ja machen wie du willst.
Es sei denn ich habe den Zusammenhang nicht richtig verstanden.. Dann sei's so.

Von der technischen Seite her macht es tatsächlich keinen Unterschied, ob du

Delphi-Quellcode:

THandle

oder

Delphi-Quellcode:

HWND

verwendest. Semantisch gesehen ist das aber eine andere Sache.

Delphi-Quellcode:

HWND

ist ein von Microsoft definierter Typ, der explizit für Window-Handles vorgesehen ist. CreateFile liefert aber ein generisches Handle (bzw. ein File-Handle). Hierfür hat MS den Typ

Delphi-Quellcode:

HANDLE

eingeführt, für den es in Delphi den Alias

Delphi-Quellcode:

THandle

gibt.

[Der schöne Günther]

Das ist im Endeffekt das gleiche wie als irgendjemand vor 15 Jahren gesagt hat "Von der technischen Seite her macht es tatsächlich keinen Unterschied, ob du

Delphi-Quellcode:

THandle

oder

Delphi-Quellcode:

Cardinal

verwendest." :P

[Zacherl]

Zitat:

Zitat von Der schöne Günther (Beitrag 1360543)

Das ist im Endeffekt das gleiche wie als irgendjemand vor 15 Jahren gesagt hat "Von der technischen Seite her macht es tatsächlich keinen Unterschied, ob du

Delphi-Quellcode:

THandle

oder

Delphi-Quellcode:

Cardinal

verwendest." :P

Naja :lol: MSDN sagt folgendes:

Code:

typedef void *PVOID;
typedef PVOID HANDLE;
typedef HANDLE HWND;

Macht in diesem Falle also tatsächlich auch in der Zukunft keinen Unterschied, sofern die Definition von HWND beibehalten wird (was aus Gründen der Abwärtskompatibilität sicherlich geschieht).

[himitsu]

Zitat:

Zitat von Zacherl (Beitrag 1360544)

sofern die Definition von HWND beibehalten wird

Nja, oder so lange sich HANDLE nicht ändert, denn auch wenn es "aktuell" der gleiche Typ ist, muß das nicht so bleiben.

z.B. könnte HWND in Zukunft 32 Bit bleiben,
aber HANDLE könnte man auf 64 Bit ändern.

PS: Für SendMessage gibt es eigentlich auch die Typen LPARAM, WPARAM und LRESULT, die Delphi zwar kennt, aber die fast niemand verwendet, noch nichtmal Delphi. :roll:



Ein Problem ist auch, das die Codevervollständigung und CodeInsight/HelpInsight den Namen des Basistypen aber nicht des verwendeten "Alias" anzeigen.
Außer man definiert etwas explizit nicht als Alias, sondern als neuer (abgeleiteter) Typ.

[Zacherl]

Zitat:

Zitat von himitsu (Beitrag 1360554)

Nja, oder so lange sich HANDLE nicht ändert, denn auch wenn es "aktuell" der gleiche Typ ist, muß das nicht so bleiben.

z.B. könnte HWND in Zukunft 32 Bit bleiben,
aber HANDLE könnte man auf 64 Bit ändern.

Ziemlich unwahrscheinlich, weil ja jetzt schon beide Typen mit der Pointer-Size skalieren.

Generell habt ihr natürlich recht, dass man bei Möglichkeit doch bitte den korrekten Typ verwenden sollte. Das wollte ich mit meiner ersten Aussage auch auf gar keinen Fall in Frage stellen. Hier sollte

Delphi-Quellcode:

HANDLE

/

Delphi-Quellcode:

THandle

verwendet werden und daran gibt es nichts zu rütteln.

[EWeiss]

Zitat:

Das ist im Endeffekt das gleiche wie als irgendjemand vor 15 Jahren gesagt hat

Ich denk sage mal nichts mehr dazu wurde ja ausreichend erklärt.

Aber das noch.
Ob ich nun nen Käfer fahre oder einen Aufgemotzten wie vor 15 Jahren bleibt sich gleich.
Zumindest was den Typ angeht.

happy code :)

gruss

[himitsu]

PS: Viele Fehler bei Programm-Umstellungen ala
32 Bit -> 64 Bit
ANSI -> Unicode (vor und ab Delphi 2009)

beruhen auf "falschen" Typen.