Merkwürdiger Effekt bei TLabel

[Willie1]

Hallo Leute,
ich habe mein Hobbyprojekt Kniffel fast abgeschlossen. Auf dem Hauptfenster befinden sich zahlreiche Labels, eine Radio Group, 4 Buttons und noch ein paar andere Steuerelemente, nichts besonderes. Zum Schluss habe ich unten noch ein großes Label eingefügt mit dem Inhalt: Peter, du bist dran, damit klar ist, wer würfeln muss (soll sich natürlich zur Laufzeit ändern). Alle Label haben individuelle Namen, das letzte Label heißt zunächst Label1. Jetzt fällt mir auf, egal ob ich Caption im Objekt Inspektor verändere oder zur Laufzeit, es steht immer nur 1 da. Bei einem zweiten Label2 2 und s.w. 3. Seht euch die Screenshots an, im Quelltext kommt Label1,2 und 3 nur in der Deklaration vor sonst nicht.
Was zum Teufel ist da los?
Gruß Willie.

[DieDolly]

Zitat:

Seht euch die Screenshots an

Welche Screenshots? ;) Ich sehe da (noch) keine.

[Delphi.Narium]

Screenshot hin, Screenshot her.

Dadrin kann man nur ein Ergebnis sehen, aber hat keine Chance irgendwas sinnvolles bezüglich der Ursache zu sagen.

Caption von TLabel wird entweder im Objektinspektor gesetzt oder zur Laufzeit.

Man müsste, wenn im Objektinspektor was sinnvolles in Caption steht, aber zur Laufzeit was anderes, im Quelltext nachschauen, ob Caption ein Wert zugewiesen wird und ggfls. welcher.

Ohne Quelltext und Formular ist es annähern aussichtslos, hier irgendeine, wenn auch nur ansatzweise, sinnvolle Hilfestellung zu geben, geschweige denn die Ursache zu finden.

[Heimlich]

Benenne Label1, Label2 und Label3 um, sprich, gib ihnen sprechende Namen. Beim Compilieren solltest Du dann merken, wo der Fehler ist.

[Willie1]

Bevor ich mich hier melde, überprüfe ich alles sehr sorgfältig. Im Quelltext kommt Label1,2,3 NUR in der Deklaration vor, ich hab's mit der Suchfunktion überprüft. Wieso steht da 1,2 und 3, es müsste doch Label1 2 und 3 stehen.

Delphi-Quellcode:

  TMainForm = class(TForm)
    MainMenu: TMainMenu;
    M_Datei: TMenuItem;
    M_NeuesSpiel: TMenuItem;
    M_Oeffnen: TMenuItem;
    M_Speichern: TMenuItem;
    M_Beenden: TMenuItem;
    M_Einstellungen: TMenuItem;
    M_Setup: TMenuItem;
    M_Spiel: TMenuItem;
    M_WeiteresSpiel: TMenuItem;
    M_Spielstand: TMenuItem;
    N3: TMenuItem;
    M_Rundeabb: TMenuItem;
    M_Hilfe: TMenuItem;
    M_Programmerkl: TMenuItem;
    M_Dank: TMenuItem;
    N2: TMenuItem;
    M_Ueber: TMenuItem;
    N1: TMenuItem;

    StatusBar: TStatusBar;
    KniffelRahmen: TBevel;
    lblWueSpieler: TLabel;
    lblWuerfelInfo: TLabel;
    lblAuswRunde: TLabel;
    lblAuswName: TLabel;
    lblKniffelKarteRunde: TLabel;
    Rahmen3: TBevel;
    lblW1: TLabel;
    lblW2: TLabel;
    lblW3: TLabel;
    lblW4: TLabel;
    lblW5: TLabel;
    NeuBox1: TCheckBox;
    NeuBox2: TCheckBox;
    NeuBox3: TCheckBox;
    NeuBox4: TCheckBox;
    NeuBox5: TCheckBox;
    lblEiner: TLabel;
    lblZweier: TLabel;
    lblDreier: TLabel;
    lblVierer: TLabel;
    lblFuenfer: TLabel;
    lblSechser: TLabel;
    lblBonus: TLabel;
    lblZwiErgebnis: TLabel;
    lblDreierpasch: TLabel;
    lblViererpasch: TLabel;
    lblFullHouse: TLabel;
    lblKlStrasse: TLabel;
    lblGrStrasse: TLabel;
    lblChance: TLabel;
    lblKniffel: TLabel;
    lblGesamtErgeb: TLabel;
    Bevel1: TBevel;
    Bevel2: TBevel;
    lblKniffelKarteUeb: TLabel;
    lblWueAuswUeb: TLabel;
    lbl_2: TLabel;
    lbl_1: TLabel;
    lbl_3: TLabel;
    lbl_4: TLabel;
    lbl_5: TLabel;
    lbl_6: TLabel;
    lblBonusZahl: TLabel;
    lblZwiErgebZahl: TLabel;
    lbl_7: TLabel;
    lbl_8: TLabel;
    lbl_9: TLabel;
    lbl_10: TLabel;
    lbl_11: TLabel;
    lbl_13: TLabel;
    lbl_12: TLabel;
    lblGesErgebZahl: TLabel;
    Bevel3: TBevel;
    lblAuswahlUeb: TLabel;
    lblEiner2: TLabel;
    lblZweier2: TLabel;
    lblDreier2: TLabel;
    lblVierer2: TLabel;
    lblFuenfer2: TLabel;
    lblSechser2: TLabel;
    lblDreierpasch2: TLabel;
    lblViererpasch2: TLabel;
    lblFullHouse2: TLabel;
    lblKlStrasse2: TLabel;
    lblGrStrasse2: TLabel;
    lblChance2: TLabel;
    lblKniffel2: TLabel;
    GroupBox1: TGroupBox;
    rbtn_1: TRadioButton;
    rbtn_A1: TRadioButton;
    rbtn_2: TRadioButton;
    rbtn_A2: TRadioButton;
    rbtn_3: TRadioButton;
    rbtn_A3: TRadioButton;
    rbtn_4: TRadioButton;
    rbtn_A4: TRadioButton;
    rbtn_5: TRadioButton;
    rbtn_A5: TRadioButton;
    rbtn_6: TRadioButton;
    rbtn_A6: TRadioButton;
    rbtn_7: TRadioButton;
    rbtn_A7: TRadioButton;
    rbtn_8: TRadioButton;
    rbtn_A8: TRadioButton;
    rbtn_9: TRadioButton;
    rbtn_A9: TRadioButton;
    rbtn_10: TRadioButton;
    rbtn_A10: TRadioButton;
    rbtn_11: TRadioButton;
    rBtn_A11: TRadioButton;
    rbtn_12: TRadioButton;
    rbtn_A12: TRadioButton;
    rbtn_13: TRadioButton;
    rbtn_A13: TRadioButton;
    lblWuePkt: TLabel;
    lblErkl1: TLabel;
    lblErkl2: TLabel;
    Wuerfel1: TDice;
    Wuerfel2: TDice;
    Wuerfel3: TDice;
    Wuerfel4: TDice;
    Wuerfel5: TDice;
    Bevel4: TBevel;
    lblZwischenstUeb: TLabel;
    lblName_1: TLabel;
    lblName_2: TLabel;
    lblName_3: TLabel;
    lblName_4: TLabel;
    lblName_5: TLabel;
    lblName_6: TLabel;
    lblSpieStand_1: TLabel;
    lblSpieStand_2: TLabel;
    lblSpieStand_3: TLabel;
    lblSpieStand_4: TLabel;
    lblSpieStand_5: TLabel;
    lblSpieStand_6: TLabel;
    Bevel5: TBevel;
    Bevel6: TBevel;
    AnimateWue: TAnimate;
    SaveDialog: TSaveDialog;
    OpenDialog: TOpenDialog;
    lblKniffelKarteName: TLabel;
    SpielGauge: TGauge;
    lblFortschr: TLabel;
    ImageList1: TImageList;
    Image1: TImage;
    Image2: TImage;
    Image3: TImage;
    Image4: TImage;
    Image5: TImage;
    Image6: TImage;
    AboutBox21: TAboutBox2;
    BitBtn1: TBitBtn;
    Button1: TButton;
    Button2: TButton;
    BitBtn2: TBitBtn;
    Label1: TLabel;
    Label2: TLabel;
    Label3: TLabel;

Zitat:

Caption von TLabel wird entweder im Objektinspektor gesetzt oder zur Laufzeit.

Ich wiederhole nochmal im Quelltext wird Label1.Caption nicht verändert.

[himitsu]

Im Grunde würde ich auch wetten, dass es etwas in deinem eigenen Code ist, aber wenn es unbedingt sein muß...

Delphi-Quellcode:

type
  TLabel = class(StdCtrls.TLabel)
  protected
    // einfacher/schöner zu Debuggen wäre es gewesen SetCaption aka SetText/SetTextBuff zu überschreiben,
    // aber das geht nicht, drum hier über WM_SETTEXT bzw. CM_TEXTCHANGED.
    procedure CMTextChanged(var Message: TMessage); message CM_TEXTCHANGED;
  end;

  TMainForm = class(TForm)
  ...
  end;
  
implementation

procedure TLabel.CMTextChanged(var Message: TMessage);
begin
  Beep;  <<<< hier ein Haltepunkt hin und dann im Stacktrace/Debugger schauen wo es her kommt, bzw. wohin es zurück geht
  inherited;
end;

[Medium]

Evtl. irgendwo ein with...do eingesetzt, dass unerwartet die Caption vom Label erwischt?

[Delphi.Narium]

Zitat:

Zitat von Willie1 (Beitrag 1463145)

Ich wiederhole nochmal im Quelltext wird Label1.Caption nicht verändert.

Ohne den vollständigen Quelltext sehe ich keine Chance, sinnvolle Hilfestellung zu geben.

Wird irgendwo im Programm die Caption von irgendwelchen anderen TLabels (in 'ner Schleife) geändert und Label1 bis Label3 werden dabei (unbeabsichtigt) mit verändert?

[bcvs]

Such mal im Quelltext nach Caption.

[himitsu]

Zitat:

Zitat von bcvs (Beitrag 1463155)

Such mal im Quelltext nach Caption.

Und Text
und ...


Selbst mit einem falschen Cast

Delphi-Quellcode:

TEdit(x).Text := ;

kann mein den Text eines Labels umschreiben. (denn es geht intern alles über's gleiche WM_SETTEXT)

[Alallart]

Zitat:

Zitat von Willie1 (Beitrag 1463145)

Bevor ich mich hier melde, überprüfe ich alles sehr sorgfältig. Im Quelltext kommt Label1,2,3 NUR in der Deklaration vor, ich hab's mit der Suchfunktion überprüft. Wieso steht da 1,2 und 3, es müsste doch Label1 2 und 3 stehen.

Ich musste zwei mal den Text lesen bis ich verstanden habe was du meinst. Und ich bin mir immer noch nicht sicher. Du solltest dir vielleicht schon die Arbeit machen und die Label-Namen ausschreiben: "Im Quelltext kommt Label1, Label2 und Label3...". Du schreibst: "Wieso steht da 1,2 und 3, es müsste doch Label1 2 und 3 stehen.". Was soll da jetzt stehen? "Label1 2 und 3" oder "Label1, Label2 und Label3"?

Mach mal ein Test und benenne Label1, Label2 und Label3 in Label7, Label8 und Label8 um. Wenn nach dem Start 7, 8 und 9 angezeigt werden, wird man das Problem schnell eingrenzen können.

[Willie1]

Hallo Freunde,
ich kann euch nicht zumuten, den gesamten Quelltext zu durchsuchen. Auch für sowas einfaches wie Kniffel hat er schon eine gewisse Länge. Ich habe den Namen von Label1 auf lblIstDran geändert und die Sache läuft. Ich bleibe dabei, das ist ein merkwürdiger Effekt, der ja auch bei Label2, ...3 usw. auftritt. Aber egal, jetzt funktioniert es.

Dann eine Frage, kann ich mein Programm irgendwie vorstellen. Kritik und Ratschläge helfen immer weiter. Es geht mir nicht um den Quelltext, da gibt es sicher viele Verbesserungen sondern um die Oberfläche und den Ablauf.

Schönen Gruß Willie.

[Aviator]

Zitat:

Zitat von Willie1 (Beitrag 1463163)

Dann eine Frage, kann ich mein Programm irgendwie vorstellen. Kritik und Ratschläge helfen immer weiter. Es geht mir nicht um den Quelltext, da gibt es sicher viele Verbesserungen sondern um die Oberfläche und den Ablauf.

Naja es gibt in der DP ein Bereich Softwareprojekte der Mitglieder. Ich denke dort wäre so etwas gut aufgehoben.

[Medium]

So wie ich das einschätze, gibt es 100x mehr sinnvolle Vorschläge bzgl. des Codes im Vergleich zu egal welcher Oberfläche du kredenzt. Wenn dir wirklich etwas an der Entwicklung liegt, fragst du besser nach ersteren.

[Delphi.Narium]

Mich interessiert Kniffel als Spiel nicht, aber mich interessiert, wie Du es programmiertechnisch gelöst hast.

Das Spiel als Exe mit Oberfläche zum Spielen kratzt mich garnicht, so wenig, dass ich es mir sicherlich nicht anschauen werde.
Zu sehen, wie man sowas in Pascal/Delphi umsetzt, fänd' ich aber schon interessant.

[Sinspin]

Hallo, auch wenn Du schon eine Lösung gefunden hast, ich kenne einen solchen Effekt von verwenden eines Localizers. Also einer Komponente die es ermöglicht das Programm in verschiedene Sprachen zu übersetzen.
So war einmal aus irgend einem Grund die Liste für die Defaultspache nicht aktualisiert worden und ich hatte zur Laufzeit immer andere Texte als zur Designzeit.

[Andreas L.]

Früher gab es mal den Fehler das ein Label nach mehrmaligen setzen der Caption nicht automatisch aktualisiert wurde. Das konnte man mit einem einfachen Refresh nach dem setzen der Caption beheben. In aktuellen Delphi-Versionen sollte es diesen Fehler aber nicht mehr geben...

Delphi-Quellcode:

  Label1.Caption := 'Hallo';
  Label1.Refresh;

[Willie1]

Hallo,
jetzt packt mich der Ehrgeiz, ich will es wissen.
Ich habe ein neues Label auf dem Formular platziert und es lblaaa1 genannt. Dann habe ich, Himitsu,

Delphi-Quellcode:

TMainForm.CMTextChanged(var Message: TMessage);

mit Beep eingefügt. Nach dem Start des Programms wird diese Routine zuerst durchlaufen (lblaaa1.Caption geändert?) es beept und es geht weiter mit MainForm.Create. Auf dem Schirm wird wieder 1 angezeigt, welchen Namen das Label hat, spielt dabei keine Rolle.
ich bin neugierig, was euch da noch einfällt.

Maigruß Willie.

[Uwe Raabe]

Ohne ein Beispiel, das dieses Verhalten reproduziert, werden wir dann wohl nicht weiter kommen. Wir können ja von hier aus nicht deinen Code sehen, geschweige denn debuggen.

[Gausi]

Zitat:

Zitat von Willie1 (Beitrag 1463163)

Hallo Freunde,
ich kann euch nicht zumuten, den gesamten Quelltext zu durchsuchen. Auch für sowas einfaches wie Kniffel hat er schon eine gewisse Länge.

Aber vielleicht sehen ja erfahrenere Delphianer den Fehler schneller. Und vielleicht ist der eine oder andere ja jetzt auch neugierig, wie man so ein komisches Verhalten herbeizaubern kann. ;-)

Wenn sich irgendwo unerwünschterweise Labels ändern, kann das ja auch durchaus auf ein tieferliegendes Problem hindeuten, was du dringen fixen solltest - und dann daraus lernen kannst. Im Screenshot im ersten Posting sieht man z.B. implizite Umwandlungen von String und Shortstring. Den Datentyp ShortString benötigt man für solche Standard-Dinge eigentlich nicht mehr. Könnte sein, dass der Fehler in diesem Kontext zu suchen ist.

[Willie1]

Genügt die PAS-Datei, wenn ich sie hier hochlade? Wi.

[Delphi.Narium]

Erstmal ja. Damit kann man schon die Logik nachvollziehen und ggfls. Problemstellen identifizieren.

[Willie1]

Das ist es.

[Delphi.Narium]

Delphi-Quellcode:

procedure TMainForm.Wuerfel_zeigen(Wue: TWuerfelPkt);
var
  i: Byte;
  Wuerfel: TDice;
  Lbl: TLabel;
begin
  for i:=1 to 5 do begin
    Wuerfel:=TDice(FindComponent('Wuerfel'+IntToStr(i)));
    Wuerfel.Value:=Wue[i];
    // --------------------------------------------
    Lbl:=TLabel(FindComponent('Label'+IntToStr(i))); // <-- Da kommt die Ziffer her!!!
    Lbl.Caption:=IntToStr(Wuerfel.Value)
    // --------------------------------------------
  end
end; {TMainForm.Wuerfel_zeigen}

procedure TMainForm.btnFertigWuerfelClick(Sender: TObject);
...
{$ENDIF}
    for i:=1 to 5 do begin
      Box:=TCheckBox(FindComponent('NeuBox'+IntToStr(i)));
      if Wahl < NeuWuerfeln then begin  //3
        if Box.Checked then begin
          Wuerfel:=TDice(FindComponent('Wuerfel'+IntToStr(i)));
          Wuerfel.Roll;
          WuerfelPkt[i]:=Wuerfel.Value;
          // --------------------------------------------
          Lbl:=TLabel(FindComponent('Label'+IntToStr(i))); // <-- Oder eventuell auch von hier!!!
          Lbl.Caption:=IntToStr(Wuerfel.Value)
          // --------------------------------------------
        end;
        Box.Checked:=false;
        Inc(Summe,WuerfelPkt[i])
      end
    end;
    Inc(Wahl);
...

[Uwe Raabe]

Ich denke, Delphi.Narium hat das richtig erkannt. In dem Form gibt es zunächst kein TLabel mit Namen 'Label1'. Ich vermute, das muss

Delphi-Quellcode:

FindComponent('lblW'+IntToStr(i))

heißen.

[Willie1]

Hallo Delphi-arium, du hast den Fehler gefunden. Ich habe die Zeilen wegkomentiert und die ominöse 1 2 … erscheinen nicht mehr. Diese Zeilen hatte ich nur zu Testzwecken eingefügt und sind überflüssig.
ABER: Es gibt keine Deklaration für Label1 (auch nicht dynamisch) und wenn ich Label1 in xyz umbenannte, kam immer noch 1.

Delphi-Quellcode:

    Lbl:=TLabel(FindComponent('Label'+IntToStr(i)));
    Lbl.Caption:=IntToStr(Wuerfel.Value)

FRAGE: wenn es Label1 nicht gibt, was passiert in Zeile 2, wenn FindKomponent nichts findet?

Bei der geringen Komplexität vom Kniffelspiel kann ich behaupten, dass das Spiel inzwischen fehlerfrei läuft.

Aber Ok - ich habe das Spiel mit Kindern, 6 u. 8 Jahre alt gespielt. Sie kamen sofort damit zurecht, fanden es am Anfang gut aber verloren schnell das Interesse.
Es ist wohl besser, wenn ich das Programm in die Ecke packe und nicht veröffentliche.

Danke für eure Hilfe und
Gruß Willie.

[Hobbycoder]

Zitat:

Zitat von Willie1 (Beitrag 1463499)

Delphi-Quellcode:

    Lbl:=TLabel(FindComponent('Label'+IntToStr(i)));
    Lbl.Caption:=IntToStr(Wuerfel.Value)

FRAGE: wenn es Label1 nicht gibt, was passiert in Zeile 2, wenn FindKomponent nichts findet?

Ich würde mal behaupten wenn FindComponent die Komponente nicht findet, gibt's ein nil zurück, und in der zweite Zeile wird dann eine Access Violation regnen.
Prüfe bei solchen Zuweisungen IMMER ob deine Variable überhaupt einen Inhalt hat. Letztlich ist Lbl in dem Fall nur ein Zeiger, und wenn der auf NIL zeigt, gibt's halt nix was man damit machen kann.

[Edit]Hab's grad mal ausprobiert. Aber es führt nicht zu einer Exception. Wahrscheinlich wird irgendwo in den Delphi-Bibliotheken auf <>nil geprüft. In dem Fall passiert nichts.[/Edit]

[Willie1]

Ja, habe es auch ausprobiert, es liefert nil zurück und in der 2. Zeile passiert nichts. Keine Exception. Sonst wäre mir mein Fehler natürlich sofort auf gefallen.
W.

[Medium]

Achtung! Wenn Lbl eine lokale Variable ist, wird sie NICHT mit nil initialisiert! Das sollte der Compiler auch mit einer Warnung anmeckern!

Daher steht dann in Lbl "irgendwas" drin, und der Zugriff auf Lbl.Caption verändert "irgendwas", was überall in dem Programm sein könnte. Ganz dicker böser Schnitzer, und 2 wichtige Regeln missachtet: 1) Warnungen sind nicht zur bloßen Kenntnisnahme da, 2) Rückgabewerte stets überprüfen. Dass nil bei Nichtfund zurückgegeben wird, steht sogar in der Hilfe zu FindComponent(). Also sollte man das auch beachten.

[Gausi]

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?

Delphi-Quellcode:

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

Die Message ist leer, aber warum läuft das ohne Zugriffsverletzung durch?

[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.