// geht auch ohne "^", da Delphi in Fall des nachfolgenden "." sich dieses "^" einfach implizit dahindenkt
Da stelle ich mich auf den Standpunkt: Wenn mans richtig macht (machen kann
), dann braucht Delphi nicht mehr zu raten. Ist vor allem dann wichtig, wenn man in einer Sprache programmiert, die so etwas nicht automatisch macht.
Zitat von
himitsu:
Das ist aber kein Problem der Sprache.
Du nutzt hier ja einen Befehl der
WinAPI und diese wird in allen Sprachen gleich angesprochen. (heißt also, unter C# würde es genauso aussehn)
"...einfach implizit dahindenkt..." bedeutet für mich: Da gehört was hin, was vielleicht nicht dort steht, aber automatisch ergänzt wird, um dem User das Leben einfacher zu machen.
Soll also (für mich) heißen: Sinnvoll zu lernen, dass da eigentlich etwas hingehört (hier ein Dereferenzierer), dann macht man es in Zukunft (hoffentlich) auch in einer anderen Sprache nicht falsch.
Oder habe ich Dich falsch verstanden?
Zitat von
Luckie:
Aber warum eigentlich per SendMessage? Ich hätte ein Ereignos ausgelöst und der Empfänger hätte sich dann das Array selber abgeholt. Und wenn man es noch weiter treiben würde, könnte man aus dem Array eine Liste machen. Und aus den Records Objekte und dann eine ObjectList nehmen.
Erstmal, weil ich den Code so übernommen habe und ihn nicht umschreiben wollte. Man kann sich nun sicherlich trefflich darüber streiten, ob das Umschreiben den "Mehrwert" (also Objekte statt Records, Objectlist etc.) lohnt, zumal es ja jetzt (mit Eurer Hilfe) soweit funktioniert, dass man drauf "aufbauen" kann.
Zur Sache Ereignis <> Message bin ich ehrlich gesagt noch nicht so bewandert, wie ich die Ereignisse definieren soll.
[edit]
Aber lass mich mal überlegen, ob ich Dich richtig verstehe:
ClassOne besitzt ein Ereignis
Delphi-Quellcode:
type TQueueTransfer = procedure(parameter : TAQueue) of object;
type TClassOne = class(TObject)
private
FQueue : TAQueue;
procedure CreateQueue;
FOnQueueCreated : TQueueTransfer;
public
property OnQueueCreated : TQueueTransfer read FOnQueueCreated write FOnQueueCreated;
end;
procedure TClassOne.CreateQueue;
begin
//Queue erzeugen und füllen
if Assigned(FOnQueueCreated) then
FOnQueueCreated(FQueue);
end;
ClassTwo besitzt eine Methode "GetQueue", welche die Queue bei einem Ereignis entgegennehmen soll.
Delphi-Quellcode:
type TClassTwo = class(TObject)
private
FClassOne : TClassOne;
procedure GetQueue(queue : TAQueue);
public
end;
Irgendwo anders (meinetwegen in einer "Superklasse") werden die beiden "verheiratet"
Delphi-Quellcode:
[...]
FClassOne := TClassOne.Create;
FClassTwo := TClassTwo.Create;
FClassOne.OnQueueCreated := FClassTwo.GetQueue;
[...]
Das würde bedeuten, dass sich ClassOne und ClassTwo nicht mehr kennen müssen.
Bisher musste ja ClasssOne eine Referenz auf das ClasssTwo.Handle speichern, was jetzt wegfallen würde. Dafür muss es eine Superklasse geben, die beide Klassen kennt und für deren Verwaltung (Create / Free) zuständig ist.
Das gefällt mir in der Hinsicht besser, da ich persönlich eine Abneigung dagegen habe, dass jeder jeden kennen muss, damit die Sache funktioniert.
Also wenn ich Dich richtig verstanden habe und das auch so funktioniert, gefällt es mir recht gut und es wäre meines Erachtens den Aufwand wert, die Chose umzuschreiben. Mal sehen, ob ich dazu Zeit finde.
p.s. was bedeutet eigentlich dieses "of object"? Dass es sich um eine Prozedur eines Objects, also um eine Methode handelt?