Typenfehler bei Wechsel von D7->XE10.1

[Captnemo]

Ich habe eine ältere Anwendung, die bisher noch unter D7 gepflegt wurde. Diese soll jetzt auf 10.1 compiliert werden.
Dabei tritt eine "für mich" nicht erklärbarer Fehler auf. Meiner Meinung nach sollte doch das hier soweit korrekt sein, oder sehe ich das falsch?

Delphi-Quellcode:

procedure ShutDown;
var
  hToken: Cardinal;
begin
   if OpenProcessToken(GetCurrentProcess, TOKEN_ADJUST_PRIVILEGES or TOKEN_QUERY, hToken) then begin // <--- [dcc32 Fehler] Main.pas(6268): E2033 Die Typen der tatsächlichen und formalen Var-Parameter müssen übereinstimmen
   .
   .
   end;

[Delphi-Laie]

Zitat:

Zitat von Captnemo (Beitrag 1361253)

Ich habe eine ältere Anwendung, die bisher noch unter D7 gepflegt wurde. Diese soll jetzt auf 10.1 compiliert werden.
Dabei tritt eine "für mich" nicht erklärbarer Fehler auf.

Richtig und falsch sind eben relativ (zur Delphi-Version). Viel interessanter als "nicht erklärbarer" wäre gewesen, welcher Fehler konkret auftritt.

Edit: OK, da steht er ja. Wurden wohl andere Typen im neuen Delphi für diese Funktion deklariert...Muß wahrscheinlich ein anderer Integertyp deklariert werden, auf Anhieb weiß ich jetzt nicht, wie der heißt. Schau mal in meinen "Prozeßbetrachter", da funktioniert es.

Edit2: Mist, andere waren schneller. NativeUInt fiel mir auch gerade ein.

[Uwe Raabe]

So sollte es gehen:

Delphi-Quellcode:

var
  hToken: THandle;

[Lemmy]

nein, passt nicht - einfach mal die Signatur der Prozedur in Delphi anschauen - das muss ein NativeUInt sein....

[Whookie]

aus Windows.pas

Delphi-Quellcode:

function OpenProcessToken(ProcessHandle: THandle; DesiredAccess: DWORD;
  var TokenHandle: THandle): BOOL; stdcall;

[Uwe Raabe]

Zitat:

Zitat von Lemmy (Beitrag 1361256)

nein, passt nicht - einfach mal die Signatur der Prozedur in Delphi anschauen - das muss ein NativeUInt sein....

Das deutet jetzt auf die übliche Diskrepanz zwischen Theorie und Praxis hin :) Nicht alles, was der Hint anzeigt steht auch wirklich so da.

[Whookie]

Zitat:

Zitat von Uwe Raabe (Beitrag 1361259)

... :) Nicht alles, was der Hint anzeigt steht auch wirklich so da.

Ja so ist das.. auf nichts ist mehr Verlass ;)

Grundsätzlich war Cardinal ja mal richtig für THandle und solange das Programm nur für 32 Bit compiliert wird sollte es auch kein Problem geben...

ABER (ja da ist immer ein "aber") sobald man das ganze für 64bit compilieren möchte wird es böse!

Daher kann ich nur empfehlen, immer in der windows.pas nachzusehen welche Parametertypen verwendet werden und diese auch unbedingt einzusetzen (das gilt insbesondere für HRESULT, LPARAM, WPARAM, LRESULT, THandle, usw.)!

[Captnemo]

THandle....das war's. Wer lesen kann, ist klar im Vorteil. Danke an alle.

[Lemmy]

Zitat:

Zitat von Uwe Raabe (Beitrag 1361259)

Zitat:

Zitat von Lemmy (Beitrag 1361256)

nein, passt nicht - einfach mal die Signatur der Prozedur in Delphi anschauen - das muss ein NativeUInt sein....

Das deutet jetzt auf die übliche Diskrepanz zwischen Theorie und Praxis hin :) Nicht alles, was der Hint anzeigt steht auch wirklich so da.

das ist sicherlich richtig - wobei ich zu meiner Verteidigung anbringen möchte, dass sich das "nein, passt nicht" auf das "Meiner Meinung nach sollte doch das hier soweit korrekt sein, oder sehe ich das falsch?" im Ausgangspost bezog und nicht auf deinen Post, der sich irgendwie ohne Meldung dazwischen geschmuggelt hat :-)

[himitsu]

Auch wenn THandle früher mal Cardinal war ...

Tja, hätte man damals den "richtigen" Typen (THandle) verwendet, hätte die Umstellung keine Probleme bereitet.


Das Selbe wie bei Unicode, hätte man die richtigen Typen genommen, wären über 95% der Codes ohne große Änderungen auch sofort in D2009+ gelaufen. :roll:

[Delphi-Laie]

Hätte...wäre...Dabei hat Delphi doch schon den Wechsel von 16 auf 32 Bit miterlebt. Damals sollten "mitwachsende" (generische?) Typen (integer, cardinal, string ohnehin) doch schon die "ultimative Zukunftssicherheit" gewährleisten. Und in der Tat waren und sind Turbo-Pascal und Delphi vorbildlich abwärtskompatibel, leider aber nicht vollständig.

[Captnemo]

Zitat:

Zitat von Delphi-Laie (Beitrag 1361301)

Und in der Tat waren und sind Turbo-Pascal und Delphi vorbildlich abwärtskompatibel, leider aber nicht vollständig.

Das bekomme ich auch gerade zu spüren. Formsize und Alignments werden fehlerhaft compiliert. Zumindest unterscheidet sich die Ansicht der Forms in der GUI und zur Laufzeit in diesen Punkte extrem. Das geht soweit, dass sich Buttons außerhalb der Form befinden, oder Komponenten schlichtweg weit über den Formrand hinausragen, und Fenster nicht die gleiche Größe haben wie in der GUI. D7 hab ich immer nur unter W7 betrieben, 10.1 jetzt aber unter W10.

Vielleicht liegt das aber auch gar nicht zwingend an Delphi. Die Ursache dafür hab ich noch nicht gefunden. Bei neuen Projekten passiert das jedenfalls nicht.

[himitsu]

Früher hatte Delphi Width/Height der Forms gespeichert, was schief gehen musste, wenn sich die Größe der Ränder ändert.
Inzwischen wird ClientWidth/ClientHeight gespeichert.

Problem ist dennoch, wenn der Desktop kleiner ist, als das Fenster zur Entwicklungszeit,
denn der VCL-Loader läd erstmal alles blind und ignoriert, wenn Windows die Fenster/Komponenten dabei verkleinert oder verschiebt.
Align und Co. wird dann aber auf die falschen Fenster-/Komponentengrößen und Positionen angewendet, womit selbst mit automatischer Ausrichtung etwas außerhalb der Form liegen bleibt.

Da kann man nur alles in ein Panel legel und das beim Start selber ausrichten.
Und alles, was rechts und/oder unten ausgerichtet wird, müsste man auch noch neu ausrichten, wenn dessen Größe falsch geladen wird.

[Uwe Raabe]

Zitat:

Zitat von Captnemo (Beitrag 1361307)

Zumindest unterscheidet sich die Ansicht der Forms in der GUI und zur Laufzeit in diesen Punkte extrem. Das geht soweit, dass sich Buttons außerhalb der Form befinden, oder Komponenten schlichtweg weit über den Formrand hinausragen, und Fenster nicht die gleiche Größe haben wie in der GUI.

Wir hatten hier ähnliche Probleme in einem D7-Projekt, wo die Controls im FormResize von Hand skaliert und positioniert werden. Das passierte aber nur, wenn man Laufzeitthemes verwendet. Nach Umstellung auf mit Align- und Anchor-positionierte Controls war das allerdings erledigt.

[Captnemo]

Okay, danke für die Tipps. Ein Deaktivieren der Hochauflösung hat erst mal alles wieder auf "Normalzustand" gebracht. Ist zwar nicht die Endlösung, aber für's erste schon mal zu gebrauchen.
Die notwendigen Änderungen lassen sich bei 240 Formen nur Stück für Stück umsetzen.

[Uwe Raabe]

Zitat:

Zitat von Captnemo (Beitrag 1361323)

Die notwendigen Änderungen lassen sich bei 240 Formen nur Stück für Stück umsetzen.

Ist hier ähnlich. Die Themes werden erst mit einem zukünftigen New-Look-Update eingeführt.