Dynamische Fenster über Funktion ansteuern

[cback]

Hallo,

ich bin momentan dabei eine neue Version von meinem MOD-Editor zu programmieren. Dabei habe ich nun ein sicher kleineres Problem und bräuchte da mal einen kleinen Denkanstoß. :zwinker:

Das Editorfenster kann mehrfach geöffnet werden, falls man mehrere Dateien bearbeitet. Das geht z.B mit so einem Code:

Delphi-Quellcode:

procedure ...;
  var EditorMOD: TEditor_MOD;
begin
  EditorMOD := TEditor_MOD.Create(self);
  EditorMOD.Caption := 'CBACK MIRO - Mod Editor';
  EditorMOD.Show;
end;

In diesem Editor gibt es unter anderem eine Prozedur die zu dem Editor Aktionen hinzufügt oder gewisse häufiger auftretende Dinge ausführt. Die kleinste Prozedur "AddAction" sieht dann (wenn man das Fenster "fest" benannt hätte) so aus:

Delphi-Quellcode:

procedure AddAction(action:string);
begin
  Editor_MOD.MiroEdit.SelText := #13#10 + '#' + #13#10 + '#-----[ ' + action + ' ]------------------------------------------'+ #13#10 + '#' + #13#10;
  Editor_MOD.MiroEdit.SetFocus;
end;

Und nun das Problem:

Da ich ja das Fenster selber neu in einem Objekt anlege ist ja der feste Name nicht mehr vorhanden. Sprich die Prozedur weiß nicht mehr auf welches angelegte Fenster sie zugreifen muss. Gibt es da vielleicht eine Funktion, mit der man angeben kann, dass in einem aktiven Fenster etwas stattfinden sollte (Bei Javaskript gibts ja z.B das "this"). Oder anderweitig diese Prozedur so erweitern, dass sie weiß welches Fenster gerade geöffnet ist und die Prozedur gestartet hat (Sender oder so?).


Danke im Vorraus für Antworten. :)

Bye
CBACK

[SirThornberry]

Was hindert dich daran die Fenster nach dem du sie erzeugt hast in einer Liste zu speichern (oder notfalls in einem Array)? damit kannst du sie später auch ohne probleme ansprechen. Wenn das Fenster dann zuerstört/freigegeben wird musst du es natürlich auch wieder aus der Liste entfernen.

[cback]

Naja gibts eventuell was performanteres? Jedes Array nimmt ja wieder bissel Arbeitsspeicher weg (gut das hält sich da noch in grenzen aber man will ja versuchen den Code so optimiert wie möglich zu schreiben) :D Außerdem wird hier:

Code:

procedure ...;
  var EditorMOD: TEditor_MOD;
begin
  EditorMOD := TEditor_MOD.Create(self);
  EditorMOD.Caption := 'CBACK MIRO - Mod Editor';
  EditorMOD.Show;
end;

ja nicht wirklich ein anderer Fenstername erzeugt, sondern nur angelegt, angezeigt, fertig. Da hätte ich dann das Problem, dass die Fensternamen ja nicht unterschiedlich sind. Ich müsste also doch irgendwie den Sender abgreifen. Nur wie? :pale:

[SirThornberry]

performanter wird es dadurch ja schon weil du die Fenster bedeutend schneller findest als wenn du alle komponenten durchgehen musst.
Bring mal ein konkretes Beispiel wo du nicht weißt auf welche Editorinstanz du zugreifen musst.
Wenn zum Beispiel in deinem erzeugten Fenster ein Btn-Click ausgelöst wird und du das ganze objectorientiert gelöst hast so bekommst du ja auch die Action in der Fensterklasse.

Das beispiel was du gepostet hast ist ja nur das erzeugen des Fensters, an welcher Stelle brauchst du denn die Fensterinstanz?

[cback]

Also wenn ich zum Beispiel im Menü auf die Aktion "OPEN" klicken will, dann wird diese Prozedur oben aufgerufen mit

AddAction('OPEN');

Wenn ich den festen Komponentennamen angebe, dann erscheint der Compilerfehler, dass auf unsichtbare oder versteckte Fenster keine Schreibaktion auf Komponenten durchgeführt werden kann.

Gebe ich den Namen des erzeugten Fensters an, welches ich mit EditorMOD angelegt habe (so werden ja alle angelegt), dann erscheint kein Fehler, aber auch kein Text in dem Editorfeld.

Verzichte ich auf die Prozedur und setze den Inhalt allerdings direkt auf den Menüklick funktioniert es, da es ja dann direkt lokal in die Komponenten eingetragen wird.


Ich scheitere da momentan daran, wie ich der Prozedur mitteile von wo ich den Button geklickt habe. Das Objekt hat ja den gleichen Namen (EditorMOD), wird immer nur nochmal neu angelegt und dann angezeigt, also da entsteht eigentlich kein anderer Name dabei. Oder vielleicht intern irgendwo?

[Daniel]

Du schreibst also eine MDI-Anwendung? Und die Routine 'addAction()' soll mit dem jeweils aktuellen Fenster etwas anstellen? Sehe ich das richtig?

Dann schaue doch mal, ob Du mit der Eigenschaft 'ActiveMDIChild' des Hauptfensters weiterkommst. Das liefert nämlich eine Referenz auf genau das Fenster, das Du suchst.

Zitat:

Jedes Array nimmt ja wieder bissel Arbeitsspeicher weg (gut das hält sich da noch in grenzen aber man will ja versuchen den Code so optimiert wie möglich zu schreiben)

Den Speicher, den dieses Array wegnimmt, kannst Du absolut vernachlässigen. Wieviele Fenster kann denn Dein Anwender gleichzeitig öffnen? Oder anders gefragt: Wieviele wird er im Schnitt tatsächlich offen haben, ohne sich in der Fenster-Liste zu verirren? Greifen wir hoch und sagen, Du hättest es mit einem Anwender zutun, der 50 Dokumente gleichzeitg im Sinn behalten kann. Dann hättest Du 50 Pointer á 32bit. Zum "optimierten" Code gehört auch eine gewisse Wartbarkeit sowie eine gewisse Lesbarkeit.

Wenn Du das, was Du beabsichtigst, mit einem solchen Array klar und verständlich in Programmcode umsetzen kannst, machst Du einen sehr großen Schritt in Richtung eines gut strukturierten Programms. Optimiere dort, wo Du tatsächlich große Mengen an Speicher und/oder Rechenzeit verbrätst. Aber nicht an den Stellen, wo es sich um 200 Bytes dreht - das lohnt sich meistens nicht.

Um nochmal auf den Ursprung zu kommen: Sehe Dir mal das MDI-Demo von Delphi an, falls Fragen zum Handling der Fenster auftauchen.

[cback]

Es ist keine echte MDI Anwendung, also die neu erzeugten Forms sind eigenständig und keine MDI Childs eines Hauptforms. Das mit dem Array ist dann wohl doch die einzige Lösung. Die Frage ist nur, da ich das Fenster immer so anlege:

Delphi-Quellcode:

procedure ...;
  var EditorMOD: TEditor_MOD;
begin
  EditorMOD := TEditor_MOD.Create(self);
  EditorMOD.Show;
end;

woher weiß ich dann wie das Fenster intern heißt? Und wie könnte ich dann auf diese Informationen in der Prozedur zugreifen? Also das Array dann auf jeden Fall schon mal superglobal anlegen damit es überall verfügbar ist. Nur dann das irgendwie ausgelesen bekommen, die Fenster selber werden immer als EditorMOD angelegt. :gruebel:


Schon mal danke an alle für die Antworten. :)

[Daniel]

Wie sehr fühlst Du Dich in der Delphi-Welt zuhause? Ich frage nur, weil ich wissen möchte, wo ich ansetzen soll, wenn ich einen Lösungs-Vorschlag skizziere.

Ich habe aber noch eine andere Frage: Wie hängen diese Fenster zusammen? Warum eine Anwendung, die mehrere Fenster startet (und doch keine MDI-Anwendung ist) und nicht mehrere Instanzen dieser Anwendung, die jeweils ein Fenster bieten? Ich denke da an eine Situation, in der man zum Beispiel 10 x Notepad.exe öffnet.

[cback]

Zitat:

Zitat von Daniel

Wie sehr fühlst Du Dich in der Delphi-Welt zuhause? Ich frage nur, weil ich wissen möchte, wo ich ansetzen soll, wenn ich einen Lösungs-Vorschlag skizziere.

Fortgeschritten würd ich mal bei diesem Thema mit Objekten sagen. :)

Zitat:

Ich habe aber noch eine andere Frage: Wie hängen diese Fenster zusammen? Warum eine Anwendung, die mehrere Fenster startet (und doch keine MDI-Anwendung ist) und nicht mehrere Instanzen dieser Anwendung, die jeweils ein Fenster bieten? Ich denke da an eine Situation, in der man zum Beispiel 10 x Notepad.exe öffnet.

Also es gibt verschiedene Editorenlayouts da ist das dann so meiner Meinung nach etwas übersichtlicher zu handhaben. Vom Leistungsverbrauch her (ich hatte erst mal mit MDI angefangen und fand das dann vom Layout her nicht so) kommt es aber aufs gleiche hinaus. Hier mal ein Screenshot wie das aussieht wenn 2 der Editorfenster geöffnet sind, das blaue dahinter ist dann das Startfenster. Darüber können dann die Editoren aufgerufen werden, sollte das Programm ohne Parameter aufgerufen worden sein (wenn das der Fall ist startet dann die geöffnete Datei automatisch im passenden Editor)

[Daniel]

Fein. :-)

Dann hst Du ja die wesentlichen Dinge schon zusammen. Dein Hauptfenster könnte dann für Deine eigene Fensterverwaltung der Dreh- und Angelpunkt werden. Dort würde ich mir eine Liste (TList) deklarieren (ich find's mit Listen einfacher als mit Arrays) und dann eine Referenz auf jedes neu erzeugte Fenster in dieser Liste ablegen:

Delphi-Quellcode:

procedure ...; 
  var EditorMOD: TEditor_MOD; 
begin 
  EditorMOD := TEditor_MOD.Create(self); 
  EditorMOD.Show;

  meineFensterListe.add( EditorMOD ); 
end;

Damit kannst Du Dir einen Überblick über alle derzeit offenen Fenster verschaffen. Jedoch musst Du ein Editor-Fenster wieder aus der Liste rauswerfen, wenn Du es schließt.

Willst Du also eine Aktion mit allen Fenstern machen, läufst Du einfach über die Liste und castest die Listenelemente auf den Typ "TEditor_MOD".

Wenn Du feststellen willst, was das aktuelle Fenster ist, so könntest Du Das Ereignis "onActivate" Deiner Editor-Fenster nutzen und in dem Ereignis-Handler Deinem Hauptfenster mitteilen, wer jetzt gerade aktuell ist:

Delphi-Quellcode:

Hauptfenster.setAktuellesEditFenster( self );  // Pseudocode...

Diese Routine "setAktuellesEditFenster()" merkt sich dann in einer Variablen die Referenz, die sie eben als Parameter erhalten hat.

Und Deiner eingangs angesprochenen Routine "AddAction" könntest Du dann als Parameter eine Referenz auf das Fenster mitgeben, mit dem sie arbeiten soll.



Aber viele Wege führen nach Rom ... mit mehr Kenntnis über die Architektur Deiner Anwendung könnte man vielleicht auch andere sinnvolle Vorschläge bringen. Unter Umständen macht es Sinn, eine Methode wie "addAction()" gleich als Methode Deines Editor-Fensters zu deklarieren. Dann könntest Du mit einem Aufruf wie

Delphi-Quellcode:

AktuellesEditFenster.addAction('');

irgendwas veranstalten.