Mehrere Fenster, gleiche Klasse,auf best. Memo zugreifen

[Kernel32.DLL]

N'Abend alle zusammen,

Ich hab ein mittelschweres Problem und steh' im Moment etwas auf dem Schlauch.

Folgendes:

Ich habe eine Komponente, die das Event "OnMessageRecv" besitzt. Es handelt sich um die TICQLib. Dieses Event wird immer dann aufgerufen, wenn mir jemand eine Nachricht schickt.

Delphi-Quellcode:

procedure TForm1.ICQClient1MessageRecv(Sender: TObject; Msg, UIN: string);

In der Variable "UIN" steckt die UIN von dem, der mir die Nachricht geschickt hat, in der Variable "Msg" die Nachricht selbst.

die komplette Prozedur sieht bei mir dann so aus:

Delphi-Quellcode:

procedure TForm1.ICQClient1MessageRecv(Sender: TObject; Msg, UIN: string);
var
  i: Integer;
  ListItem: TListItem;
begin
 with TsendMsgFrm.Create(nil) do
    begin
      if ListView1.Items.Count > 0 then
        for i := 0 to ListView1.Items.Count - 1 do
          if ListView1.Items.Item[i].Caption = UIN then
          begin
            ListItem := ListView1.Items.Item[i];
            FNick := ListItem.SubItems[LV_INDEX_NICK]; //Nick
            Break;
          end;
      if FNick = UIN then
        Caption := Format('Chat with "%s"', [UIN])
      else
        Caption := Format('Chat with "%s" (%s)', [FNick, UIN]);
      Jvrichedit1.selattributes.Color := clNavy;
      Jvrichedit1.selattributes.Style := [fsBold];
      Jvrichedit1.Lines.Add(FNick + ':');
      Jvrichedit1.selattributes.Color := clBlack;
      Jvrichedit1.selattributes.Style := [];
      Jvrichedit1.Lines.Add(Msg);
      Jvrichedit1.Lines.Add('');
end;
end;

mein Problem ist jetzt:

Ich habe bei dem Fenster sowohl das Memo, in dem ich meine Nachricht schreibe als auch das Memo, wo ich die Antwort meines Chat - Partners lesen kann. Das Problem ist jetzt:

Wenn ich jetzt bereits das Chat - Fenster geöffnet habe und die Antwort meines Partners erhalte, dann wird das Fenster erneut geöffnet, was natürlich nicht sein sollte. Ich habe zur Verdeutlichung meines Problems mal einen kleinen Bildband angehängt, denn Bilder sagen mehr als tausend Worte.

Meine Frage also:

Wie kann ich auf die einzelnen Memo's zugreifen, wenn ich mehrere Chatfenster geöffnet habe?

Mit

Delphi-Quellcode:

sendmsgfrm.Jvrichedit1.Lines.Add(Msg);

geht es ja nicht, denn woher soll das Programm wissen, welches Chatfenster ich meine?


Nachdem ich euch jetzt vollends verwirrt habe, hoffe ich trotzdem auf hilfreiche Antworten.


mfg
kernel32.dll

[_Sebastian_]

merke dir doch die erstellten Fenster in einer Liste und überprüfe dann ob für die uin schon ein fenster besteht.

Ich würde da ne TStringList / THashedStringList nehmen. Da kannste dann ne Bezeichnung und ein object speichern und über indexof leicht überprüfen ob in der liste schon ein fenster für die uin ist.

[Robert_G]

Die UIN sollte ja eindeutig sein. ;)
Eine möglichst einfache Lösung wäre dann wohl eine Art Factory, die dir anhand der UIN eine Instanz einer "ChatSession" liefert.
Ist die UIN noch nicht in der Liste würde eine neue Instanz erstellt und zurückgegeben werden. Welche sich in dem Moment gleich den Nick von ICQ holen kann. ;)

Dürfte also eigentlich gar nicht schwer sein. ;) Nur solltest du deinen Code-Style überdenken.
Was du da machst gehört zur grundlegenden Logik des Programmes. Da haben Formulare absolut nix zu suchen. ;)
Man sieht es sehr deutlich an deiner Methode. Du hantierst dort mit einem ListView, seinen Items, einem Form und einem Memo auf dem Form rum. Außerdem bestzt du den Nick, obwohl das das Objekt selbst machen könnte.
Kein Wunder wenn du die Übersicht verlierst. ;)

Es könnte, auf den Punkt gebracht, so aussehen:

Delphi-Quellcode:

Session := Sessions[UIN];
Session.Message.Add(Msg);
Session.Activate();

Sessions wäre deine "Factory" (@maximov ich weiß, dass es keine ist ;) ).
Session ware deine Abbildung einer ICQ Session. Die Klasse würde intern das Formular verwalten.

Diese 2 (oder mehr) Klassen zu implementieren dürfte nichtmehr wirklich schwierig sein. auf der anderen Seite gewinnst du damit Modularität und Übersicht. :)
Ich meine, was interessiert die Klasse, die auf das Receive horcht, welche Caption das Nachrichtenfenster bekommen soll, welchen Nickname der Sender hat oder in welcher Farbe/Style der Nick auf ein RichEdit kommt.
Auch dieses RichEdit interessiert den "Horcher" überhaupt nicht.

[new4toms]

Meine absolut unprofessionelle und in der DP höchst verpönte Antwort (schon wegen der Tippfehler): Eine globale, booleansche Variable...

[Robert_G]

Zitat:

Zitat von new4toms

Meine absolut unprofessionelle und in der DP höchst verpönte Antwort (schon wegen der Tippfehler): Eine globale, booleansche Variable...

Ich hoffe mal, das war ein Witz. Da es mehrere Instanzen des Nachrichtenfensters gibt, dürfte eine globale Variable Blödsinn sein. ;)

[Kernel32.DLL]

danke für die vielen Antworten!

@Robert_G:
Ich denke, ich werde heute Abend wohl die DP-Suche bemühen, weil ich keine Ahnung hab', was eine "Factory" ist und wie das mit "Session" und "Sessions" gemeint ist. Und dann müsst ich noch herausfinden, wie ich denn auf das Memo eines schon vorhanden Fensters vom Typ TSendMsgFrm zugreifen könnte.

(Oder kann mir das jemand in der Zwischenzeit noch erklären :stupid: )

gruß
kernel32.dll

[Kernel32.DLL]

Frage hat sich (hoffentlich) erledigt, denn...

Ich glaube, ich habe gefunden, was ich gesucht hab'. Und zwar hier: Delphi-Forum
War ja doch net so schwer.... :oops:

@Robert: Ich hab immer noch nicht kapiert, wie du das meinst....

[Robert_G]

Ich dachte, eine gewisse Modularisierung und lesbare Strukturen wären von Vorteil. ;)
Also zum beispiel ein Klasse, die dir alle aktuellen ChatSessions verwaltet und dir einfach über die UIN eine zurückgibt bzw. eine neue erzeugt, in ihre Liste packt und diese zurückgibt.

Das was du da hast ist .. nunja .. messy ;)
Die eigentliche Logik eines Programmes sollte keinerlei GUI Elemnte enthalten. Das fesselt dir beide Hände und macht eine Wiederverwendbarkeit unmöglich.
Wie ich oben bereits schrieb: Allein diese eine Methode ist krass zugestopft mit allem möglichen, was diese Methode eingentlich gar nciht interessiert.

Aber ich glaube, ich höre lieber auf etwas Interesse für OOP wecken zu wollen.
Es besteht hier anscheinend nicht der Hauch von Interesse daran. :roll:
Bastelt ruhig weiter eure komischen, hässlichen Dingsen. :thuimb:

[Kernel32.DLL]

Zitat:

Zitat von Robert_G

Aber ich glaube, ich höre lieber auf etwas Interesse für OOP wecken zu wollen.
Es besteht hier anscheinend nicht der Hauch von Interesse daran. :roll:
Bastelt ruhig weiter eure komischen, hässlichen Dingsen. :thumb:

"Sarkasmus ist es, was uns am Leben erhält."

Was heißt kein Interesse. Ich musste ja nur erstmal kapieren, was du überhaupt meinst. Ja, eine Modularisierung wäre vom Vorteil... We'll see....

[Robert_G]

Das war mehr allgemein gehalten.
Ich habe in den letzten Wochen immer etwas in diese Richtung gepiekt. Einfach um zu sehen wieviel Interesse bzw. Grundwissen da ist.
Mit beidem scheint es beim durchschnittlichen Fragesteller nicht weit her zu sein.
Es würde sich für mich also nicht lohnen Zeit in Tutorials zu OOP im allgemeinen bzw. zur Implementierung von ein paar Patterns zu schreiben.
Die einzigen, die sich dafür interessieren würden, könnten es ja schon.

Also nimm's nicht persönlich. ;)