![]() |
Aktives MDIChild nach Schliessen eines MDIChild
Hallo!
Ich habe eine MDI-Anwendung. Dort sind beispielsweise 3 MDIChilds offen. Schliesse ich eins, wie bekomme ich heraus welches das nächste aktive MDIChild ist? Habe schon versucht eine Message vom MDIChild zur Hauptanwendung zu senden beim Schliessen. Das geht aber nicht, da dass zu schliessende MDIChild noch aktiv ist. In der Hauptform wird OnPain und OnActive nicht aufgerufen. Hat jemand eine Idee? Vielen Dank schon mal im voraus! Stephan |
AW: Aktives MDIChild nach Schliessen eines MDIChild
ActiveMDIChild??
|
AW: Aktives MDIChild nach Schliessen eines MDIChild
Nein, sitzt es nicht.
Wie ich schon beschrieben habe, bekomme ich immer noch das zu schliessende Fenster zurück. Was ich brauche, ist eine Stelle, die ausgeführt wird, wenn das Fenster weg ist und dann das richtige aktive Fenster zurückgibt. |
AW: Aktives MDIChild nach Schliessen eines MDIChild
kenn das problem, hab vor jahren mal ne mdi-anwendung mit
turbo-pascal geschrieben.. du mußt die message wm_mdinext verschicken.. jetzt weiß ich nicht mehr genau ob an das zu schließende mdichild oder an das mdi-hauptfentser. mußte mal probieren. |
AW: Aktives MDIChild nach Schliessen eines MDIChild
daraus etwas basteln?
Delphi-Quellcode:
//MDIForm
procedure TForm1.FormClick(Sender: TObject); begin With TForm2.Create(self) do begin name := 'Nr1' ; end; With TForm2.Create(self) do begin Name := 'Nr2' end; end; // Child procedure TForm2.FormActivate(Sender: TObject); begin Form1.Caption := Name; end; |
AW: Aktives MDIChild nach Schliessen eines MDIChild
Da weiß ich jetzt nicht, was das in diesem Zusammenhang bedeuten soll.
Es geht um MDI-Formen. Ich weiß nicht, ob du weißt was ein Multi-Document-Interface ist... |
AW: Aktives MDIChild nach Schliessen eines MDIChild
Wozu musst du das eigentlich wissen?
Und WER muss das wissen? Muss es das Hauptformular wissen oder alle restlichen MDI-Form? Das globale Objekt Screen hat übrigens das Event OnActiveFormChange. |
AW: Aktives MDIChild nach Schliessen eines MDIChild
@wolfgang_SV
Die meisten meine Anwendungen sind MDI-Anwendungen, aber ich sehe nicht wo das Problem des TE liegt. Beim schließen eines MDI-Forms wird das nächste sofern vorhanden aktiv. Das jeweils aktive kann ich über ActiveMDIChildanfragen. Da er anscheinen auf das schließen eines MDIChilds reagieren will und den Destruktor nicht vorgesehen hat, sehe ich einen Ansatz darin festzustellen wann ein anderes Child aktiviert wurde. |
AW: Aktives MDIChild nach Schliessen eines MDIChild
Zitat:
|
AW: Aktives MDIChild nach Schliessen eines MDIChild
Zitat:
Es gibt normerweise keinen Grund das aktive MDI-Child nach dem Schliesen eines anderen MDI-Childs in Erfahrung zu bringen. Wenn man wüsste wozu du das brauchst dann könnte man Dir auch einen sinnvollen Rat geben. |
AW: Aktives MDIChild nach Schliessen eines MDIChild
Ich will es ja auch gar nicht wissen..
Handson wollte es wissen , zumindest hab ich so seine Anfrage verstanden. |
AW: Aktives MDIChild nach Schliessen eines MDIChild
Dafür weist wenigstens Du was eine MDI-Anwendung ist.:thumb:
|
AW: Aktives MDIChild nach Schliessen eines MDIChild
ja du doch auch, denk ich.
ich weiß nur nichts mit deinem delphi-code anzufangen.. |
AW: Aktives MDIChild nach Schliessen eines MDIChild
Der Sinn, wozu ich den Namen brauche ist recht einfach. Unten kurz oberhalb der Statusleiste ist ein TabControl. Für jedes offene MDI mache ich ein Tab auf, so dass man damit durch die einzelnen Childs durchklicken kann. Meine MDI sind immer maximiert und können nicht kleiner gemacht werden, daher kann man nicht anders wechseln.
Nun, wenn sich ein Child schließt, dann bekommt der Tab eine Meldung, dass er sich sich löscht. Das geht, aber ich möchte das Tab für das jetzige aktive Child auch in den Vordergrund bringen , also auch auf Aktiv setzen. Und daran scheitert es momentan bei mir. Soweit die Problembeschreibung. |
AW: Aktives MDIChild nach Schliessen eines MDIChild
dann setze das Tab doch im OnActivate der MDI-Children.
Aber die Beschreibung klingt eher so als ob Du eine SDI-Anwendung haben wolltest bei der Forms auf einem Tabsheet gedockt werden... |
AW: Aktives MDIChild nach Schliessen eines MDIChild
der Aufruf sendmessage(client,wm_mdigetactive,0,0)
liefert dir das handle des aktiven MDI_childwindows zurück, wobei client das handle des MDI_clientwindows ist.. |
AW: Aktives MDIChild nach Schliessen eines MDIChild
Zitat:
Kann man denn nicht irgendwie die Haupt-Anwednung fragen, welches seiner MDI's gerade aktiv ist? Gibt es denn nicht irgendein Event, dass ausgelöst wird, wenn gerade ein MDI geschlossen wird? |
AW: Aktives MDIChild nach Schliessen eines MDIChild
Hi !
Grundsätzlich hat Bummi hier Recht. Was Du beschreibst ist am Besten über ein TabSheet und gedockte Forms zu realisieren. MDIs sind dann überflüssig und die ganze Problematik stellt sich erst gar nicht. Wenn Du Dir das einmal ansehen möchtest wie sowas funktioniert, dann such mal in YouTube nach "Delphi Programming Tutorial #32 - Dockable Forms" und "Delphi Programming Tutorial #33 - Dockable Forms 2" Da Du aber offenbar schon mit den MDIs angefangen hast ... Die Holzhammer-Methode wäre mit Hilfe tApplicationEvents.OnIdle in Deiner MainForm zu überprüfen, ob sich MainForm.ActiveMDIChild geändert hat. - (Würde ich aber nicht empfehlen) Alternativ setzt Du den Tab mit dem OnActivate-Event der einzelnen MDI-Children. Schließt Du den aktuellen MDI-Child, bekommt ein anderes (sofern vorhanden) den Focus und löst diesen Event aus. Solltest Du Zugang zu den TMS-Komponenten haben gibt es noch eine weitere sehr komfortable Lösung : das tAdvOfficeMDITabSet - Hier fügst Du im Create Deines MDI-Childs den Befehl
Code:
ein und die Komponente übernimmt alles weitere. Der Tab wird geschlossen, wenn der MDIChild geschlossen wird, Du kannst den Child auch über den Tab schließen etc...
MainForm.AdvOfficeMDITabSet.AddTab(MDIChild);
Ich hoffe, das hilft Dir weiter. |
Alle Zeitangaben in WEZ +1. Es ist jetzt 04:25 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024-2025 by Thomas Breitkreuz