array per message in eigener anwendung versenden

[himitsu]

stümmt

OK, wenn du nur lesend drauf zugreifen willst, dann müßte es so gehn.

Delphi-Quellcode:

SendMessage(classTwo.handle, wm_my_notify, WPARAM(FQueue), 0);

test := TAQueue(msg.wparam)[0].Level;

Das nutzt den internen Zeiger des Arrays. Dieses ist aber nur solange gültig/möglich, wie das Array nicht beim Empfänger verändert wird.

über @ und ^ müßte es eigentlich auch gehn, nur daß man hier einen Zeiger auf die Variable übergibt, wo dann auch Änderungen mäglich wären.

Das as ist nur für Objekte (und neuerdings auch für Interfaces) und nicht für "normale" Typen, wie ein Array.

[Luckie]

Und um LPARAM würde ich die Länge mit schicken.

[silver-moon-2000]

Zitat von himitsu:

Das nutzt den internen Zeiger des Arrays. Dieses ist aber nur solange gültig/möglich, wie das Array nicht beim Empfänger verändert wird.

Wird es nicht. Im Empfänger wird es nur gelesen.

Zitat von himitsu:

Das as ist nur für Objekte (und neuerdings auch für Interfaces) und nicht für "normale" Typen, wie ein Array.

Und wieder was neues gelernt...

Zitat von himitsu:

OK, wenn du nur lesend drauf zugreifen willst, dann müßte es so gehn.

Zitat von Luckie:

Und um LPARAM würde ich die Länge mit schicken.

Oh man, diese Mittagspause hat sich wirklich gelohnt. Ich könnte Euch beinahe knutschen. Beinahe!

[himitsu]

Zitat von Luckie:

Und um LPARAM würde ich die Länge mit schicken.

bei einem/diesem dynamischen Array ist die Länge doch eingebaut

du kannst auch nur eine bestimmtes Item übergeben:

Delphi-Quellcode:

type PQueueItem = ^RQueueItem;

SendMessage(classTwo.handle, wm_my_notify, WPARAM(@FQueue[0]), 0);

test := PQueueItem(msg.wparam)^.Level;
// geht auch ohne "^", da Delphi in Fall des nachfolgenden "." sich dieses "^" einfach implizit dahindenkt

PS: Laut M$ sollte man besser die Typen WPARAM, LPARAM und RPARAM LRESULT (für's Result) verwenden, statt deinem Cardinal.

[silver-moon-2000]

Zitat von himitsu:

du kannst auch nur eine bestimmtes Item übergeben:

Delphi-Quellcode:

type PQueueItem = ^RQueueItem;

SendMessage(classTwo.handle, wm_my_notify, WPARAM(@FQueue[0]), 0);

test := PQueueItem(msg.wparam)^.Level;
// 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:

PS: Laut M$ sollte man besser die Typen WPARAM, LPARAM und RPARAM LRESULT (für's Result) verwenden, statt deinem Cardinal.

wurde notiert und geändert.

Nochmals danke für Deine / Eure Zeit & Mühe

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

Bitte.

[Luckie]

Gerade C# ist ein schlechtes Beispiel, wegen dem unmanaged code. Ich hätte eher C oder so als Beispiel genannt. 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.

[silver-moon-2000]

Zitat von silver-moon-2000:

Zitat von himitsu:

// 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?

[xZise]

Zitat von silver-moon-2000:

p.s. was bedeutet eigentlich dieses "of object"? Dass es sich um eine Prozedur eines Objects, also um eine Methode handelt?

Du hast es erfasst.

Und so hast du es auch für spätere Projekte gelernt und musst nicht mehr den Umweg über SendMessage machen. Gerade in Delphi ist die Implementierung ziemlich einfach was das angeht. Wenn ich da an Java denke graust es mir schon

MfG
Fabian

[Luckie]

Eventuell solltest du dir das mal angucken: http://www.michael-puff.de/Artikel/C...rKlassen.shtml und dir mal mein Memory angucken: http://www.michael-puff.de/Programmi...ckieMemory.zip