Eigenen Cursor zuweisen

[TomyN]

Hallo,

seit langer Zeit nutze ich die folgenden Zeilen um in der Resource gespeicherte selbstdefinierte Cursoren (? Cursors?) zu laden.

Delphi-Quellcode:

procedure TSATMAT.LoadCursors;
var
  CursorLoadID: HIcon;
begin
  CursorLoadID := LoadCursor(hInstance, 'CUCURVE');
  screen.Cursors[cuCu] := CursorLoadID;
  CursorLoadID := LoadCursor(hInstance, 'CUPEQQ');
  screen.Cursors[cuPEQ] := CursorLoadID;
  CursorLoadID := LoadCursor(hInstance, 'REDDOT');
  screen.Cursors[cuRD] := CursorLoadID;
  CursorLoadID := LoadCursor(hInstance, 'CURED');
  screen.Cursors[cuRed] := CursorLoadID;
end;

Das hat bisher immer funktioniert, nun bekam ich von einem Kunden einen Fehlerbericht, der hier einen Out of Range Error (win10 / 64) berichtete.
Da bin ich aktuell etwas ratlos, denn die Doku und die Beispiele, die ich finde, geben keinen Hinweise.

Vielleicht hat ja jemand von Euch eine Idee.

Tomy

[himitsu]

Wie sind cuCu und Co. deklariert?

Zitat:

HIcon

Statt HICON meinst du natürlich HCURSOR, aber fast egal, da sie identisch sind.

Zumindest in Delphi 12 passt es ... wie es in Delphi 10 aussah, weiß ich jetzt nicht,
also bezüglich der Typen für Screen.Cursors, LoadCursor und HICON/HCURSOR.

Und ob innerhalb des Screen.Cursors-Setters alles passt, hab ich noch nicht geprüft. (erstmal nur schnell dein Codeschnipsel)


In aktuelleren Delphis ist nun standardmäßig die Bereichsprüfung aktiviert (Delphi 10.3 eigentlich noch nicht),
bei Zuweisung von Int64 zu Int32, bzw. zwischen Int und UInt (und Dergleichen), kann es somit nun knallen, wenn es z.B. negativ wird.

[TomyN]

Delphi-Quellcode:

Const
...
  cuCu =                1;   //Cursor ID für's Malen
  cuPEQ      =          2;   //PEQ Cursor
  cuRD       =          3;   //Red - Dot
  cuRED      =          4;

Da hab ich schon drüber nachgedacht, da ich eher was wie

Delphi-Quellcode:

CursorLoadID := LoadCursor(hInstance, 'CUPEQQ');
cuPeq := screen.cursors.add(CursorLoadId);

erwarten würde.
Drum frag ich ja

[TomyN]

War bis gestern trivial THandle, dann hab ich mich mal auf Delphi verlassen, und da wurde bei MouseOver hIcon als Rückgabewert angezeigt

Ansonsten ist mir das Problem auch noch nie begegnet und der Code läuft so seit Jahren auf vielen Systemen, daher würde ich es auch nicht überbewerten.

[himitsu]

Zitat von TomyN:

War bis gestern trivial THandle, dann hab ich mich mal auf Delphi verlassen, und da wurde bei MouseOver hIcon als Rückgabewert angezeigt

So ganz Falsch war das auch nicht ... war zumindest "kompatibel".

Was oftmal knallte, da Delphi teilweise falsche Typen genutzt hatte, z.B. Signed anstatt Unsigned,
dass dann teilweise irgendwann berichtigt hatte oder es mit anderen "richtigen" API-Deklaration kollidiert,
wenn es nicht richtig zusammen passt. (oder weil der Entwickler das nicht bemerkt und seine Typen angepasst hat, oder er es eben selbst ausversehn falsch gemacht hatte)

Delphi versucht seit einer Weile Typen strikter zu prüfen.
Und wenn auch noch die Überlaufprüfung aktiv ist, dann wird nicht mehr blind überschieben oder gar abgeschnitten, sondern der tatsächliche Wertebereich zur Laufzeit geprüft, mit dem aktuellen Variablen-Inhalt.

z.B. wenn das System eine Weile läuft, dann gehen die Handle/Indize/Counter hoch
und irgendwann sind sie eventuell "zu groß", für falsche Typen.

Wie z.B. Pointer in Integer zu casten.
Integer ist kein dynamischer Typ mehr (war es noch zwischen Win16 und Win32), aber mit Win64 wurde er eingefrohren und ein neuer Typ (NativeInt) erfunden. (war nicht die Idee von Embarcadero, sondern Microsoft/Intel/AMD/...)

Delphi-Quellcode:

type
  THandle = NativeUInt;

  UIntPtr = NativeUInt;
  UINT_PTR = System.UIntPtr;  // NativeUInt;
  HICON = type UINT_PTR;
  HCURSOR = HICON;              { HICONs & HCURSORs are polymorphic }

function LoadCursor(hInstance: HINST; lpCursorName: LPCWSTR): HCURSOR;

Ja, von der TypeInfo her ist es HICON (das "alte" CodeInsight ging nur auf TypeInfos),
aber wenn man in die Deklaration schaut, "eigentlich" HCURSOR.

HCURSOR ist ein Alias auf HICON. (ist also kein eigenständiger Typ)


Neuere Delphis, seit Delphi 11.irgendwas oder 12, versuchen im CodeInsight und HelpInsight das "richtiger" darzustellen.
z.B. wurde früher bei LPARAM "Integer" angezeigt (im Win32), was im Prinzip stimmte, aber unter Win64 ist es eben ein Int64 (oder UInt64).

Wenn man da seine Variable "blind" als Integer deklariert, dann knallt es irgendwann, wenn sich der "eigentliche" Typ mal ändert, sei es durch Änderung der API, oder weil es ein compilerabhängiger Typ ist.

[Uwe Raabe]

Ich vermute das Problem an einer ganz anderen Stelle. Ich würde nochmal überprüfen, ob es wirklich dort passiert. Falls doch, könnte ich mir eher sowas wie einen Buffer-Overflow vorstellen, aber das halte ich doch für recht unwahrscheinlich.