Assigned

[Pseudemys Nelsoni]

hoi,

ja ich weiss, wurde in einem anderem thread (nebenbei) erklärt, aber ich versteh diese funktion nicht ganz....das heisst wie sie funktioniert weiss ich schon, nur die verwendung versteh ich bei einigen sachen nicht. Gerade in der klassenprogrammierung wie z.b das hier:

Delphi-Quellcode:

procedure TNumEdit.KeyPress(var Key: Char);
begin
  if not Key in ['0'..'9'] then
  begin
    if Assigned(OnFehler) then
      OnFehler(Self);  
    key:=#0;
  end;
  inherited KeyPress(Key);
end;

( Source: http://www.delphi-treff.de/content/t...dex.php4?kat=6 )


ich weiss das assigned true ist wenn OnFehler nicht nil ist, aber ich verstehe nie WANN hier OnFehler nil ist und wann nicht und wie es hier geprüft wird...ich verstehs irgendwie alles nich mit dieser doofen funktion :?

[Sanchez]

Hallo,

Eine Membervariable einer Klasse ist von "Natur aus" nicht zugewiesen. D.h. Integers sind 0, Strings sind Leerstrings und Pointer sind nil, usw ...

Die Funktion Assigned überprüft jetzt, ob der Parameter <> nil ist.
Der Pointer OnFehler ist also am Anfang nil. Wenn er erstmalig zugewiesen wird, zeigt er nicht mehr auf nil, sondern irgendwo in den Speicher. Jetzt gibt Assigned(OnFehler) true zurück.

Nachdem du das nächste mal OnFehler nil zuweist, wird Assigned wieder false zurückgeben.

Wenn du jetzt allerdings ein erzeugtes Objekt mit Free freigibst, wird Assigned trotzdem true zurückliefer, weil der Pointer noch irgendwo in den Speicher zeigt.

z.B.

Delphi-Quellcode:

var Liste : TStringlist;
begin
  Liste := TStringlist;  

  Liste.Free;

  if Assigned(Liste) then begin
    Liste.Add('abc'); //<-- hier gibts ne AV
  end;
end;

Deshalb sollte man statt .Free FreeAndNil() verwendet, weil es der Variable gleich nil zuweist.

Ich hoffe das war verständlich.

grüße, daniel

[EDIT] Hoppla, bei den Tags verklickt [/EDIT]

[Chewie]

OnFehler ist wohl ein Event. Events sind nichts weiter als Zeiger auf Methoden, die meist als Properties implementiert sind. Beim Erzeugen des Objekts existieren keine Ereignisbehandlungsroutinen, OnFehler ist also nil. Erst wenn eine Behandlungsroutine gesetzt wird (MyObject.OnFehler := MyEventHandler), ist Onfehler nicht mehr nil. Durch die Prüfung mit Assigned wird Onfehler also nur aufgerufen, wenn es auch gesetzt ist.

[Treffnix]

OnFehler wird ein Event der Klasse TNumEdit sein. Das heisst, es ist eine Procedure of object, die von ausserhalb erst zugewiesen werden kann ( nicht muss ).

Beispielsweise wie das onClick eines Buttons.
Wenn dem Ereignis keine Prozedur zugeordnet ist, ist das Event nil. Würde man versuchen eine nichtexistente Prozedur aufzurufen, gäbs ne Exception. Daher muss man das vorher prüfen.

[Pseudemys Nelsoni]

Hallo Sanchez,

danke für die ausführliche beschreibung;), soweit hatte ich das auch schon verstanden. Ich verstehe es nur nicht wieso es in meinem beispiel benutzt wird (klar verstehe ich es das assigned da prüft ob OnFehler<>nil ist)... ich kapiers irgendwie nicht....fragen wir mal anders...wieso sollte der geprüfte methodenzeiger denn nil sein? sorgt man beim programmieren nicht sowieso vorher dafür das das ding irgendwo hinzeigt bevor man es benutzt(womit aissgned überflüssig wäre)?

Zitat:

OnFehler ist wohl ein Event. Events sind nichts weiter als Zeiger auf Methoden, die meist als Properties implementiert sind. Beim Erzeugen des Objekts existieren keine Ereignisbehandlungsroutinen, OnFehler ist also nil. Erst wenn eine Behandlungsroutine gesetzt wird (MyObject.OnFehler := MyEventHandler), ist Onfehler nicht mehr nil. Durch die Prüfung mit Assigned wird Onfehler also nur aufgerufen, wenn es auch gesetzt ist.

wer setzt denn OnFehler? ich dachte eigentlich das man das bereits in der klasse alles drin hat hm.

Zitat:

OnFehler wird ein Event der Klasse TNumEdit sein. Das heisst, es ist eine Procedure of object, die von ausserhalb erst zugewiesen werden kann ( nicht muss ).

was heisst das von ausserhalb? wenn ich z.b eine komponente habe , dann im OI irgendeinem ereignis ein code hinzufüge...ist das mit zuweisen gemeint?

Delphi-Quellcode:

Beispielsweise wie das onClick eines Buttons. 
Wenn dem Ereignis keine Prozedur zugeordnet ist, ist das Event nil. Würde man versuchen eine nichtexistente Prozedur aufzurufen, gäbs ne Exception. Daher muss man das vorher prüfen.

Genau das ist irgendwie meine Frage, wieso sollte ich in meiner klasse versuchen die prozedur aufzurufen wenn sie nicht da ist. ich meinte wer tut denn das hmmm.

hab da so ne theorie... ist das so gemeint, das wenn ich bei einem button z.b kein OnClick ereignis definiert habe und dann versuche mit button1.click die procedure aufzurufen? oder wie?

danke für eure antworten :oops:

[Treffnix]

Stell dir vor, TButton wurde von dir programmiert. Du weisst, wann der Benutzer auf den Button klickt. Was machst du nun? Du animierst den Button erstmal ein bisschen, damit es nach Klick aussieht und nun? Woher weisst du, was der Programmierer machen will, wenn einer auf den Button klickt? - Du schaust nach, ob dem OnClick-Event eine externe Prozedur zugewiesen ist. Wenn ja, rufst du sie auf.

Nichts anderes ist das bei dem OnFehler. Dem Event muss keine Prozedur zugewiesen sein, aber vielleicht will der Programmierer, der deine Komponente benutzt ja im Fehlerfall reagieren, z.B. eine Fehlermeldung ausgeben. Dann kann er dem Event eine Prozedur zuweisen, in der er das macht.

[Steve]

Hi,

nimm als Beispiel mal TButton.OnClick her...

Solange Du dem OnClick nichts zuweist (z.B. PROCEDURE TForm1.Button1Click(Sender: TObject); ), wird bei einem Klick darauf nichts ausgeführt, da Assigned(OnClick)=NIL (Genauer: in TControl Assigned(FOnClick)) ist.

Gruß
Stephan

{edit: wiedermal zu langsam :mrgreen: }

[Pseudemys Nelsoni]

Zitat:

Du schaust nach, ob dem OnClick-Event eine externe Prozedur zugewiesen ist. Wenn ja, rufst du sie auf.

das meine ich ja, wann genau tu ich denn das? ich meine im OnClick selbst brauch ich das ja nicht prüfen ob assigned ist, weil doe prozedur ja nur aufgerufen wenn überhaupt etwas in der OnClick routine ist, oder?

Zitat:

Solange Du dem OnClick nichts zuweist (z.B. PROCEDURE TForm1.Button1Click(Sender: TObject); ), wird bei einem Klick darauf nichts ausgeführt, da Assigned(OnClick)=NIL (Genauer: in TControl Assigned(FOnClick)) ist.

gleiche frage wie oben, wo und wann wird das geprüft :oops: :oops: :oops:

[woki]

Zitat:

Zitat von Pseudemys Nelsoni

hab da so ne theorie... ist das so gemeint, das wenn ich bei einem button z.b kein OnClick ereignis definiert habe und dann versuche mit button1.click die procedure aufzurufen? oder wie?

Eben.

Hinter jedem Event im Objektinspector steht ein Methodenzeiger, fast alle davon sind nil, bzw sind nil bis du einen Eventhandler implementierst. Die Abfrage prüft also, ob ein Eventhandler, der ausgeführt werden soll, zugewiesen wurde. Diese Architektur macht Klassen viel flexibler einsetzbar, als wenn man immer eine neue Klasse ableiten müßte, um Änderungen bei der Behandlung von events zu implementieren. Und wie könnte soetwas wie Delphi sonst funktionieren?

Grüsse
Woki

[Treffnix]

Zitat:

Zitat von Pseudemys Nelsoni

das meine ich ja, wann genau tu ich denn das? ich meine im OnClick selbst brauch ich das ja nicht prüfen ob assigned ist, weil doe prozedur ja nur aufgerufen wenn überhaupt etwas in der OnClick routine ist, oder?

Eben. Sonst gibts nen Fehler. Und genau deshalb musst du das prüfen.
Du befindest dich aber ( im Beispiel ) innerhalb der TButton-Klasse. Das OnKlick ist ein Property, das von dir nach aussen gelegt wird. Und erst wenn jemand, der eine Instanz deiner Klasse erzeugt, diesem Property etwas zugewiesen hat, kannst du die zugewiesene Prozedur auch aufrufen. Im Falle des Buttons geschieht das, wenn du feststellst, dass der Benutzer mit der Maus auf deinen Button klickt. In deinem Beispiel wäre das sobald deine Klasse einen Fehler feststellt.