Frame To Frame Zugriff?

[ThomasBab]

Zitat von Popov:

@ThomasBab

Werde es testen. Bisher habe ich Probleme es zu öffnen.

Ist die zip kaputt?

Ansonsten: es ist ein Lazarus-Projekt. Aber ein Blick in die pas-Dateien sollte die Idee zeigen.

[Sir Rufo]

@Popov

Stell dir so ein Frame wie eine normale Komponente vor (TEdit, TButton, etc.) die du dir eben aus vielen einzelnen Komponenten zusammenbauen kannst. Das trifft die Art und Weise von einem Frame am Besten.

Nimm z.B. ein DBGrid, ein DBNavigator und eine DataSource und verstöpsel diese auf dem Frame. Dann dieses Frame auf eine Form und nur noch der Frame-DataSource ein DataSet geben und fertig.

[Popov]

@Sir Rufo

Ich hab die Hilfe auch gelesen, das steht auch in etwa: Frame ist weniger wie Formular, mehr wie eine Komponente. Ich verstehe was du meinst. Trotzdem fragte ich ich ob es eine Möglichkeit gibt. Schließlich lagerte ich alles in die Frames, damit die Haupt-Unit nicht so voll ist. Nun muss ich trotzdem darüber steuern.

@ThomasBab

Nein, er konnte einige Komponenten nicht finden. Habe v. 1.2.

[ThomasBab]

Zitat von Popov:

@ThomasBab

Nein, er konnte einige Komponenten nicht finden. Habe v. 1.2.

Achso, deshalb sagte ich ja, dass ich nicht extra ein eigenes Projekt anlegen wollte, sondern einfach eins "aus meinem Fundus" hochgeladen habe.

Aber die fehlenden Komponenten kannst Du einfach ignorieren. Die Idee für die dynamischen Frames kommt auch mit den Standardkomponenten zu Tage (hoffe/denke ich).

[bcvs]

Gib dem Button von Frame2 eine Ereignisbehandlngsroutine auf Formularebene:

Auf dem Form1 Doppelklick auf den Button in Frame2. Wenn der Button im Frame schon ein OnClick hat, steht dann da schon automatisch Frame2.ButtonOnClick(Sender); Danach schreibst du den Code zum Färben von Frame3.Panel rein.

Wenn man so eine Aktion nicht an ein Click- oder ähnlichen Ereignis hängen kann, arbeite ich gerne mit selbstdefinierten Events, über die das Form benachrichtigt wird, wenn etwas zu tun ist.

[WoGe]

Hi,

Zitat von Popov:

Was mir natürlich aufgefallen ist, das ist, dass Frames im Gegensatz zu Formularen keine Variable anbieten, womit sie ja nicht angesprochen werden können. Nicht direkt, von Frame zu Frame.

Also ich meine diese Aussage ist falsch. Ein Frame ist nichts anderes als ein Object , das nur etwas anders konstruiert wird als eine Klasse. Ein Frame kann sehr wohl eigene Variable und Properties haben.
spendiert man dem Frame ein Property vom Typ TFrame und weist an passender Stelle diesem property einen anderen instanziierten Frame zu, kann man auch auf diesen anderen Frame direkt zugreifen.
Gruß
wo

[DeddyH]

Ich habe eher das Gefühl, dass die globale Variable innerhalb der Formularunit gemeint ist. Die ist ja nur dem Konzept der automatischen Formularerzeugung geschuldet (Application.CreateForm in der dpr), ansonsten bräuchte man sie nicht.

[Headbucket]

Ist das bereits zu viel für die Hauptunit?

Delphi-Quellcode:

procedure TForm1.FormCreate(Sender: TObject);
begin
  Frame2.Button1.OnClick := Frame3.DoColorPanel;
end;

Delphi-Quellcode:

procedure TFrame3.DoColorPanel(Sender: TObject);
begin
  //if Sender is TButton then
  Panel1.Color := clRed;
end;

Oder ist das schlechter Programmierstil?

So funktioniert es auf jeden Fall.

Grüße
Headbucket

[himitsu]

Zitat:

Oder ist das schlechter Programmierstil?

Ja.

Bau das Event in den Frame ein und da kann sich Form1 dann dranhängen.
* entweder ein Event in den Frame, im Frame einen Eventhandler an den Button und da drin das Event aufrufen
* oder ein EventProperty in den Frame und im Getter/Setter den Eventhandler an das Property des Buttons weiterreichen

[Delbor]

Hi zusammen

Ich verzichte hier darauf, irggendeinen Thread direkt zu beantworten; anstelle dessen hier meine Umsetzung (die letztlich die Frage beantwortet):

Ich habe zwei (Basis-)Frames - ich weiss, dass der Ausdruck Basisframe offiziell nicht existiert, benutze ihn aber trotzdem, um den Unterschied zu den Frameinstanzen zu verdeutlichen.

• Einen ToolBoxFrme, der eine Werkzeugleiste mit Buttons zum Ausschneiden, Kopieren, Einfügen etc. enthält, und
• Einen SyneditFrame, der eine entsprechende Komponente birgt.

Das OnClickEvent eines Buttons im ToolBoxFrame feuert ein Event - testweise hab ich einen eigenen Typ für dieses Event definiert, damit ich einen Parameter mit abfeuern kann. Ein Event TNotifyEvent würde allerdings genügen.
Der SynEditFrame definiert den Eventhandler, der die entsprechende Aufgabe im Synedit ausführt, beispielsweise selektierten Text in die Zwischenabage kopiert oder ausschneidet.
Umgekehrt wird bei MouseUp eine Event gefeuert, wenn SelText Text enthält ist - der Eventhandler im ToolbuttonFrame stellt Enabled der entsprechenden Buttons.Im Hauptformular habe ich lediglich die Zuordnung der Events an ihre Eventhandler:

Delphi-Quellcode:

procedure TDelborWebServerMain.FormCreate(Sender: TObject);
  var Event: String;
begin
  SideBarWebFrame1.FileTreeFrame1.OnFileFound := DoOnFileFound;
  ToolBoxWebFrame1.OnPCtrlActivePage :=  DoOnPCtrlActivePage;
  SideBarWebFrame1.FileTreeFrame1.OnPathlist := DoOnPathList;

  ManageEvents;
end;

procedure TDelborWebServerMain.ManageEvents;
begin
  ToolBoxWebFrame1.OnCutOnClipBoard :=  SynEditFrame1.DoCutOnClipBoard;
  ToolBoxWebFrame1.OnCopyOnClipBoard :=  SynEditFrame1.DoCopyOnClipBoard;
  ToolBoxWebFrame1.OnPasteFromClipBoard := SynEditFrame1.DoPasteFromClipBoard;
  ToolBoxWebFrame1.OnOnSafe := SynEditFrame1.DoOnSafeSynedit;
  ToolBoxWebFrame1.OnOnOpen := SynEditFrame1.DoOnOpenSynedit;
  ToolBoxWebFrame1.OnOnNew := SynEditFrame1.DoOnNewSynedit;
  SynEditFrame1.OnSelectText := ToolBoxWebFrame1.DoOnSelectText;
end;

Damit tauschen die beiden Basisframes direkt untereinander Events aus. Um einen Basisframe per Code zu erreichen, muss dessen Instanz im Formular angesprochen werden.
Der Sinn des ganzen? Mir ging es nicht darum, den 'Umweg über das Formular' nicht gehen zu müssen, sondern darum, die Frames möglichst ohne Anpassung des Codes wiederverwenden zu können.

Gruss
Delbor