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. ;)

[maximov]

Zitat:

Zitat von Robert_G

...Sessions wäre deine "Factory" (@maximov ich weiß, dass es keine ist ;) ).

und ich weiss, dass du weisst, dass das keine factory ist :mrgreen: "factory" trifft es aber ganz gut. Um ehrlich zu sein fällt mir für ähnliche fälle auch meist keine bessere bezeichnung ein...egal hauptsache man weiss was gemeint ist.

@Tutorials: So darfst du das nicht betrachten, denn fragesteller, die sich nicht sofort der OOP in ihrer gänze und schönheit hingeben, sind nur die spitze des eisberges. Unterhalb der kasserkante schwimmen mindestens 80% die vermutlich doch daran interessiert sind mehr zu erfahren, aber nix sagen wollen, weil sie möglichweise als OOP-minderbemittelt hingestellt werden könnten. Mach doch ruhigt besagte tutorials, anstatt immer auf den ungläubigen rumzuhacken, dann kannst du denen ganz elegant deinen Gohonzon zu fressen geben :angel2:

[Johnny_W]

Zitat:

Zitat von 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.
Die einzigen, die sich dafür interessieren würden, könnten es ja schon.

Also nimm's nicht persönlich. ;)

[OT oder wie man hier so sagt]
Ich glaube nicht das man pauschal sagen kann: fehlendes Interesse. De facto ist es doch so, daß obiges Vorgehen oftmals verwendet wird weil es für potentielle "OOP Neulinge" schneller geht bei kleineren Projekten und anfangs der Vorteil der OOP nicht gesehen wird.
Darüber hinaus, schau dir mal die OOP Tuts an, die man so findet, Fahrzeug->Auto->Fahrad
Methoden beschleunigen, bremsen etc. Konkrete Beispiele braucht das Land.
Damals ist mir das mal aufgefallen,daß es anders nicht geht, weil ich eine paar Komponenten austauschen musste am Ende des Projektes, dienten nur zur Anzeige/Manipulation von Strings, aber da hingen ein paar Zeilen dran. Dazulernen kann man immer früher oder später,vom alten Hasen immer :mrgreen: , deswegen begrüße ich deine noch latente Manifestation OOP Tutorials zu verfassen.
Also...es gibt nicht nur solche, sondern auch solche. :gruebel:
[OT]

[Robert_G]

Och menno... :cry:
Da denkt man, man hat eine prima Ausrede gefunden um sich mehr Chrome zu widmen... Und dann sowas! :shock:

Und da maximov als erster das wort erhoben hat, wird er gleich als Erster mit eingespannt. :mrgreen:

gute Nacht...

[maximov]

Zitat:

Zitat von Robert_G

Och menno... :cry:
Da denkt man, man hat eine prima Ausrede gefunden um sich mehr Chrome zu widmen... Und dann sowas! :shock:

Und da maximov als erster das wort erhoben hat, wird er gleich als Erster mit eingespannt. :mrgreen:

gute Nacht...

Guten tag...

Und da du hier der rädelsführer bist, musst du erstmal deine motivation unter beweiss stellen und ein richtig gutes tutorial anfertigen, dann können wir weitersehen :mrgreen: ...zumindest muss die marschrichtung mal festgelegt werden, denn das beispiel ' Fahrzeug->Auto->Fahrad ' zeigt schon recht deutlich, dass die meisten OOP einfach als reines ableitungs-gelöte betrachten und dabei völlig übersehen, was für mächtige funktionalitäten und konzepte ihnen dabei entgehen. Deshalb solltest du vielleicht eher ein Design/architektur-tutorial machen, um den begriff OOP nicht überzustrapazieren :-D