Merkwürdiger Effekt bei TLabel

[Alallart]

Warum soll es eine geben? Nur weil es nil ist, bedeutet es nicht, dass man keinen Wert zuweisen kann.

Delphi-Quellcode:

  Lbl := TLabel(Nil);
  // Lbl := Nil funktioniert auch
  Lbl.Caption:='wuppdi';
  Showmessage(Lbl.Caption);

  Lbl := Label1;
  Showmessage(Lbl.Caption);

[Gausi]

Das hier gibt erwartungsgemäß eine Exception:

Delphi-Quellcode:

TMyClass = class
  caption: String;
end;
//
var myClass: TMyClass;
begin
    myClass := Nil;
    myClass.caption := 'foo';
end;

Definiere ich die Variable myClass aber als TLabel, gibt es keine. "Zaubert" die VCL da was, oder ist das eine versteckte Einstellung, die ich noch nicht kenne?

(Das ist ja nicht wirklich OT. Willie hatte gewissermaßen "toten" Code im Projekt, der eigentlich Fehler verursachen sollte, der aber einfach "nichts" tat und erst "aktiv" wurde, als ein passendes Label auf der Form war.)

[jaenicke]

Zitat:

Zitat von Gausi (Beitrag 1463514)

Da muss ich mich jetzt aber auch mal einklinken. Wenn FindComponent Nil zurückliefert, wenn die Komponente nicht gefunden ist, dann ist Lbl ja klar definiert. Warum knallt das denn nicht, wenn man auf die Caption von "Nil" zugreift?

Weil das ganze über Windows Messages läuft. Diese werden in TControl.Perform erzeugt und an die WindowProc übergeben. Davor wird aber Self auf nil geprüft und in dem Fall die WindowProc schlicht gar nicht aufgerufen.

Zitat:

Zitat von Gausi (Beitrag 1463517)

"Zaubert" die VCL da was, oder ist das eine versteckte Einstellung, die ich noch nicht kenne?

Zaubern ist etwas zu viel gesagt, aber ja, es wird abgefangen.

[Medium]

Zitat:

Zitat von Gausi (Beitrag 1463514)

Da muss ich mich jetzt aber auch mal einklinken. Wenn FindComponent Nil zurückliefert, wenn die Komponente nicht gefunden ist, dann ist Lbl ja klar definiert. Warum knallt das denn nicht, wenn man auf die Caption von "Nil" zugreift?

Uff, ja da war ich etwas neben der Spur. Sorry. Natürlich ist Lbl nach dem Aufruf klar definiert! Weiß auch nicht, was für ein Effekt da durch meinen Kopf ging.

[Hobbycoder]

Zitat:

Zitat von Medium (Beitrag 1463511)

Dass nil bei Nichtfund zurückgegeben wird, steht sogar in der Hilfe zu FindComponent(). Also sollte man das auch beachten.

Ja, das dacht ich auch. Ein kurzer Blick hat mich eines Besseren belehrt. Ich kann im Hilfetext von FindComponent keine Erläuterung des Rückgabewerts, wenn die Komponten nicht gefunden wird, nicht entdecken.

Zitat:

Gibt an, ob der Komponente eine bestimmte Komponente untergeordnet ist.

FindComponent gibt diejenige Komponente im Array Components zurück, deren Name mit dem String im Parameter AName übereinstimmt. Mit Hilfe von FindComponent können Sie feststellen, ob eine bestimmte Komponente einer anderen Komponente untergeordnet ist.

Bie den Komponentennamen wird die Groß-/Kleinschreibung nicht berücksichtigt.

Wobei das allerdings auch ohne weitere Erwähnung in OH klar sein sollte.

[Medium]

Zitat:

Zitat von Hobbycoder (Beitrag 1463523)

Ja, das dacht ich auch. Ein kurzer Blick hat mich eines Besseren belehrt. Ich kann im Hilfetext von FindComponent keine Erläuterung des Rückgabewerts, wenn die Komponten nicht gefunden wird, nicht entdecken.

:shock: Mir war so, als hätte ich das mal irgendwann vor Jahren da gelesen. Aber das ist genau so ein Mist, weshalb ich die Hilfe in Delphi so scharf kritisiere. So etwas muss da stehen! Mögliche Rückgabewerte sind geradezu das Minimum, was eine Funktionsbeschreibung machen muss. Und dann auch gern kleine Best-Practice Beispiele der Art

Delphi-Quellcode:

var
  edit: TEdit;
begin
  edit := FindComponent('Edit1') as TEdit;
  if Assigned(edit) then
  begin
    // your code here
  end;
end;

(Wobei ich jetzt gerade nicht sicher bin, ob "as" nicht auch schon implizit auf nil prüft, bzw. es als ungültige TEdit Instanz ablehnt. Steht bestimmt in der Hilfe dazu :) ) Und dann auch die Gefahren abgrenzen, die z.B. bei einem harten Cast entstehen können. Mag für viele offensichtlich sein, aber den meisten, die die Hilfe oft beanspruchen müssen gerade vielleicht nicht.

[Uwe Raabe]

Zitat:

Zitat von Medium (Beitrag 1463530)

(Wobei ich jetzt gerade nicht sicher bin, ob "as" nicht auch schon implizit auf nil prüft, bzw. es als ungültige TEdit Instanz ablehnt. Steht bestimmt in der Hilfe dazu

1. tut es
2. tut es nicht
3. tut es

Ein

Delphi-Quellcode:

TObject(nil) as TEdit

ist immer noch

Delphi-Quellcode:

nil

. In der Hilfe steht explizit:

Zitat:

Zur Laufzeit muss Objekt eine Instanz von Klasse oder einem ihrer Nachkommen bzw. nil sein. Andernfalls wird eine Exception ausgelöst.

[himitsu]

as knallt, wenn es ein falscher/inkompatibler Typ ist,
und nil ist kein Typ, also ein gültiger Wert.

is prüft dagegen, ob es ein kompatibler Typ ist, also nil oder was Anderes ergeben False.


Bei nil reagieren die beiden Funktionen also unterschiedlich.

[Willie1]

Zitat:

Gausi: (… Willie hatte gewissermaßen "toten" Code im Projekt, der eigentlich Fehler verursachen sollte, der aber einfach "nichts" tat und erst "aktiv" wurde, als ein passendes Label auf der Form war.)

So ist es. Aber ich bleibe dabei, mit einer Exception an dieser Stelle hätte ich das nicht übersehen.

Willie.