Delphi-PRAXiS - array per message in eigener anwendung versenden

Zitat:

Zitat von silver-moon-2000 (Beitrag 1040788)

Zitat:

Zitat von himitsu (Beitrag 1040777)

Delphi-Quellcode:

			// 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 :wink:), 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:

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:

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:

:arrow: 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;

:arrow: 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;

:arrow: Irgendwo anders (meinetwegen in einer "Superklasse") werden die beiden "verheiratet"

Delphi-Quellcode:

			[...]

FClassOne := TClassOne.Create;

FClassTwo := TClassTwo.Create;

FClassOne.OnQueueCreated := FClassTwo.GetQueue;

[...]

:arrow: 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?